control access from active directory

SUSE Product Topics SLES Configure-Administer
1

How do I control who can log in from Active Directory?

I currently use Centrify for Active Directory control and am looking to use the built in access in SLES. I have successfully joined the domain and can log in with my Windows network account. How can I restrict who can log in from the Windows side?

In CentrifyDC I can control remote access to the server and sudo rights via AD groups.

Thanks,
Joe

2

On Fri, 06 Jul 2012 17:24:01 +0000, joerabbi wrote:
[color=blue]

How do I control who can log in from Active Directory?

I currently use Centrify for Active Directory control and am looking to
use the built in access in SLES. I have successfully joined the domain
and can log in with my Windows network account. How can I restrict who
can log in from the Windows side?

In CentrifyDC I can control remote access to the server and sudo rights
via AD groups.[/color]

Not being familiar with the tools you’re using, it’s not clear what you
mean.

One doesn’t log in /from/ Active Directory, one might use AD credentials
to authenticate.

But is the authentication to access resources on the SLE server (and BTW,
which version are you using?), or authenticating against the server to
access web resources, or … what?

Need some more detail about what specifically you’re trying to accomplish
and what the end result you’re looking for is.

Jim

–
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner

3

Sorry, I am trying to use AD credentials to log into the SLES server. I installed the “Windows Domain Membership” package in Yast and I am able to log into the server using AD credentials, however, anyone in the Domain can now log into the server as well. I wish to control who can log into the server remotely via an AD group like we do for our Windows servers.

We are currently using CentrifyDC to give us this interface and control between SLES and AD. With CentrifyDC we create a group in AD and the members can access resources and log in to the server, everyone else cannot.

I am on 11 sp2 for this test. We have 10 and 11 installed in our enterprise.
Thanks,
Joe

4

On Fri, 06 Jul 2012 19:44:01 +0000, joerabbi wrote:
[color=blue]

Sorry, I am trying to use AD credentials to log into the SLES server. I
installed the “Windows Domain Membership” package in Yast and I am able
to log into the server using AD credentials, however, anyone in the
Domain can now log into the server as well. I wish to control who can
log into the server remotely via an AD group like we do for our Windows
servers.

We are currently using CentrifyDC to give us this interface and control
between SLES and AD. With CentrifyDC we create a group in AD and the
members can access resources and log in to the server, everyone else
cannot.[/color]

If the tool lets you configure a default shell by group membership, you
could define that shell as /bin/false - that’s the usual way to restrict
login access on *nix systems.

http://www.centrify.com/resources/chalktalk_group_policy.asp looks like
it might talk about what you’re trying to do as well.

Jim

–
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner

5

On 07/06/2012 12:24 PM, joerabbi wrote:[color=blue]

How do I control who can log in from Active Directory?

I currently use Centrify for Active Directory control and am looking to
use the built in access in SLES. I have successfully joined the domain
and can log in with my Windows network account. How can I restrict who
can log in from the Windows side?

In CentrifyDC I can control remote access to the server and sudo rights
via AD groups.[/color]

Let’s say you only want “domain admins” to be able to login.

Create a directory for /usr/local/etc if it doesn’t exist.

Create a file called /usr/local/etc/allowgroups and place the following lines
inside:

root
domain admins

Next edit the file /etc/pam.d/common-auth and add the following at the top of
the rules there:

auth    requisite       pam_listfile.so item=group sense=allow
file=/usr/local/etc/allowgroups onerr=fail

Oh… and if possible, keep a root shell to host alive and leave it alone while
testing all of this (don’t want to shut out root for example if it’s needed,
etc. by making a typo… right?)

The test is pretty easy… if you try to ssh in as somebody NOT belonging to
either the group root or “domain admins”, you won’t even get an opportunity to
get at a password prompt via ssh.

Not saying this is the “best” way to do what you want… just presenting a
possibility… (do a man on pam_listfile, you can do something similar using an
allowed user list etch… and likewise, you could deny instead of allow).

Also, just general pam… I picked on auth. The pam_listfile works in just
about all management groups… e.g. session, etc.

6

[QUOTE=Jim Henderson;5493]On Fri, 06 Jul 2012 19:44:01 +0000, joerabbi wrote:
[color=blue]

If the tool lets you configure a default shell by group membership, you
could define that shell as /bin/false - that’s the usual way to restrict
login access on *nix systems.

http://www.centrify.com/resources/chalktalk_group_policy.asp looks like
it might talk about what you’re trying to do as well.

Jim

–
Jim Henderson, CNA6, CDE, CNI, LPIC-1, CLA10, CLP10
Novell Knowledge Partner[/QUOTE]

Jim, thanks for the reply. We are currently using Centrify and it is working fine.

I am trying to eliminate Centrify and do the same thing natively. When we first started, SLES did not support AD by itself and we needed Centrify to control access to our Linux systems. I think I should be able to use AD authentication natively now without Centrify, I am just trying to figure out how to configure AD group rights on the SLES system without Centrify.

I was able to join the domain and all authenticated AD users are able to log in to the SLES server. Now I want to restrict access via AD groups, administrators able to log in and have sudo rights and developers or users able to log in without sudo and perhaps restricted rights (read only).

I am not certain how to reference AD groups or users in SLES configurations. Do I need to install kerberos or Pam to make this work or is the Window Domain package sufficient?

I am reading the “SUSE Linux Enterprise Server 11 SP2 Security Guide” but there seems to be some pieces missing.

Thanks,
Joe

7

Hi Joe,

I’m not familiar with the inner structures of AD, but as this is LDAP, after all, you ought to have a chance to control access to a SLES server like with other LDAP-based group memberships. In /etc/ldap.conf, you can set the following statements

pam_member_attribute member pam_groupdn <dn of the group in AD>

that will tell PAM to check that the dn of the user entry (used to validate its credentials) need to be a value of the attribute “member” of the AD group’s entry, as given by “”.

In other words, if you have proper group entries in AD, then you only need to tell pam the DN of the group and which attribute of the group to look at.

Regards,
Jens

8

Joe,

maybe I was a bit quick in my response… I’ve found the following description on how to get the “LDAP” way of connecting to AD to work: http://www.linuxquestions.org/questions/linux-enterprise-47/rhel4-authentication-to-windows-2003-active-directory-371848/#post1907850 Does that cover how you managed to “join the domain and all authenticated AD users are able to log in to the SLES server”? Or did you go the winbindd way?

From the description I’ve linked to above I cannot clearly determine how the group membership is stored in AD’s LDAP tree - but you ought to be able to explore that i.e. via “gq” or another LDAP browser.

Regards,
Jens

9

Jens, thanks, you and others have pointed me in the direction that I was thinking I needed to go in. I am thinking that pam is the controlling application.
I had installed kerberos, thinking that was the missing piece, but that just seemed to make matters worse. The installation of CentrifyDC included an install of pam, so I suspected that it made settings there.
I will experiment with settings in pam and see if that works.

Thanks everyone for the help,
Joe

10

Greetings,
I’ve tried both ideas and no joy. I get messages to the effect that the module does not recognize the user.
What I have noticed in the messages logs is that “nss_ldap could not search ldap server”, “winbindd: kerberos_kinit_password server.domain.priv failed” and unix2_chkpwd: pam_winbind(gdm:auth): user ‘username’ granted access" when I can log in successfully.
If I run “getent passwd” all I get is local accounts, if I run “wbinfo -u or -g” I get blank prompts.

I think that the source of the problem may be that the system cannot search the ldap server. Is there supposed to be an account setup for access to the ldap server? Am I missing something in the setup? I am not configuring TLS/SSL, is that likely a problem?

When changing ldap.conf or common_auth, do I need to restart anything?

Thanks,
Joe

11

On 07/12/2012 09:34 AM, joerabbi wrote:[color=blue]

Greetings,
I’ve tried both ideas and no joy. I get messages to the effect that
the module does not recognize the user.
What I have noticed in the messages logs is that “nss_ldap could not
search ldap server”, “winbindd: kerberos_kinit_password
server.domain.priv failed” and unix2_chkpwd: pam_winbind(gdm:auth): user
‘username’ granted access" when I can log in successfully.
If I run “getent passwd” all I get is local accounts, if I run “wbinfo
-u or -g” I get blank prompts.

I think that the source of the problem may be that the system cannot
search the ldap server. Is there supposed to be an account setup for
access to the ldap server? Am I missing something in the setup? I am
not configuring TLS/SSL, is that likely a problem?

When changing ldap.conf or common_auth, do I need to restart anything?

[/color]

I don’t try to integrate ldap style… I strictly use winbind for auth. Works
well for me.

12

[QUOTE=cjcox;5616]On 07/12/2012 09:34 AM, joerabbi wrote:[color=blue]

I don’t try to integrate ldap style… I strictly use winbind for auth. Works
well for me.>[/color][/QUOTE]

It seems that I am getting authenticated via winbind. How would I set up winbind to gather group info from the AD?

Shouldn’t wbinfo -u and -g show AD users and groups?

Thanks,
Joe

13

On 07/12/2012 11:44 AM, joerabbi wrote:[color=blue]

cjcox;5616 Wrote:[color=green]

On 07/12/2012 09:34 AM, joerabbi wrote:

I don’t try to integrate ldap style… I strictly use winbind for auth.
Works
well for me.>[/color]

It seems that I am getting authenticated via winbind. How would I set
up winbind to gather group info from the AD?

Shouldn’t wbinfo -u and -g show AD users and groups?

Thanks,
Joe

[/color]

See:
winbind enum groups
winbind enum users

in man smb.conf

14

[QUOTE=cjcox;5496]On 07/06/2012 12:24 PM, joerabbi wrote:[color=blue]

Let’s say you only want “domain admins” to be able to login.

Create a directory for /usr/local/etc if it doesn’t exist.

Create a file called /usr/local/etc/allowgroups and place the following lines
inside:

root
domain admins

Next edit the file /etc/pam.d/common-auth and add the following at the top of
the rules there:

auth    requisite       pam_listfile.so item=group sense=allow
file=/usr/local/etc/allowgroups onerr=fail

[/QUOTE]

Hmmm… I can create a file called allowusers and authorize a user by entering domain\username in the file, however, I don’t seem to be able to do the same with a group. Neither a built in group like domain admins or a global group like gg_linuxusers.
Odd that users work and not groups???

Thanks,
Joe

15

On 07/13/2012 11:54 AM, joerabbi wrote:[color=blue]

cjcox;5496 Wrote:[color=green]

On 07/06/2012 12:24 PM, joerabbi wrote:[color=blue][color=darkred]

[/color]
Let’s say you only want “domain admins” to be able to login.

Create a directory for /usr/local/etc if it doesn’t exist.

Create a file called /usr/local/etc/allowgroups and place the following
lines
inside:
[color=darkred]

[/color][/color]
Code:
--------------------[color=green][color=darkred]
[/color]
root
domain admins
[/color]
--------------------[color=green][color=darkred]
[/color]

Next edit the file /etc/pam.d/common-auth and add the following at
the top of
the rules there:
[color=darkred]

[/color][/color]
Code:
--------------------[color=green][color=darkred]
[/color]
auth requisite pam_listfile.so item=group sense=allow
file=/usr/local/etc/allowgroups onerr=fail
[/color]
--------------------[color=green][color=darkred]
[/color]

[/color]
Hmmm… I can create a file called allowusers and authorize a user by
entering domain\username in the file, however, I don’t seem to be able
to do the same with a group. Neither a built in group like domain
admins or a global group like gg_linuxusers.
Odd that users work and not groups???[/color]

What I typed is straight from a very new SLES 11 SP2 install which is AD joined
to the domain as a domain member server. The solution works fine for me… and
I’m actually using it now to limit logins on my host to “domain admins” group
(and root).

getent group works.

getent passwd works.

In both cases, I get full results, including the AD records.

In my /etc/nsswitch.conf I have:

passwd: compat winbind
group:  compat winbind

In my smb.conf global section I have (note I do have winbind use default domain
set to true):

[global]
workgroup = MYGROUP
passdb backend = tdbsam
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
include = /etc/samba/dhcp.conf
logon path = \\\\%L\\profiles\\.msprofile
logon home = \\\\%L\\%U\\.9xprofile
logon drive = P:
usershare allow guests = No
idmap gid = 10000-20000
idmap uid = 10000-20000
realm = MYGROUP.LOCAL
security = ADS
template homedir = /home/%D/%U
template shell = /bin/bash
winbind offline logon = yes
winbind refresh tickets = yes
winbind use default domain = true
winbind enum users = yes
winbind enum groups = yes
server string = My Portal
netbios name = Portal

And my krb.conf

[libdefaults]
default_realm = MYGROUP.LOCAL
clockskew = 300
#       default_realm = EXAMPLE.COM

[realms]
MYGROUP.LOCAL = {
kdc = mydc.mygroup.local
default_domain = mygroup.local


admin_server = mydc.mygroup.local
}
#       EXAMPLE.COM = {
#                kdc = kerberos.example.com
#               admin_server = kerberos.example.com
#       }

[logging]
kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log
default = SYSLOG:NOTICE:DAEMON
[domain_realm]
.mygroup.local = MYGROUP.LOCAL
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
minimum_uid = 1
}
16

If you check out the interwebs ans google, there SHOULD be a straight forward method to achieve that.

All sources say that it would work to modify a PAM configuration file, like
/etc/pam.d/common-auth and add the following parameters to the pam_winbind line:

require_membership_of=adgroupname-without-domain-prefix

so it looks like this

auth required pam_winbind.so use_first_pass require_membership_of=YourAdGroupname-without-domain-prefix

But for some ****ed up reason this well common configuration just WONT WORK for me on SLES 11 SP1.

I wonder why!!!

The Same line (but with ADNAME\ prefix) worked just fine on the PAM configuration file for SSHD. But SAMBA seems to ignore this completely.

17

I asume by “restrict who can log in” you mean “how to restrict who active directory user can access the samba server” or even more precicely “a share”.

Today after multiple days of fight and angryness i finaly solved that problem with SLES 11sp1.

Here is how:

SLES11 is joined to the AD Domain. yet all settings are SuSE defaults.

modify /etc/pam.d/common-auth or create your own /etc/pam.d/sshd to restrict SSH login to a specific AD Group. I did it like this:
`
#%PAM-1.0

custom made SSHD PAM configuration to restrict/controll

SSH Logins of Active Directory Users to the Linux Server.

Created: 2012-10-31 by A.Werner [mail@awerner.homeip.net]

auth requisite pam_nologin.so
#auth include common-auth
auth required pam_env.so
auth sufficient pam_unix2.so
auth required pam_winbind.so use_first_pass require_membership_of=youAdDomain\\yourAdGroupName

account requisite pam_nologin.so
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
`

Disabled all samba shares that are enabled and configured by SuSE default using yast

using yast, add or edit your share for the AD Users to use and ADD the following parameter to it to restrict access to the share itself:
Valid Users = @yourDomainName\\yourAdGroupName

since the “HOME” share is already restricted to the user itself, there is no need to do additional stuff.

Seems to work quiet well for me.
I wonder why SuSE just wont add these details to their SLES Manuals.
Man! Linux manuals often realy suck!!!
Hopefully this wont.

good luck!
Axel Werner

18

axel1973 wrote:
[color=blue]

I wonder why SuSE just wont add these details to their SLES Manuals.[/color]

Sometimes, it’s just an oversight.

If you go to the online documentation, you can leave a comment and ask
them to include something that’s missing or correct something that
needs it.

https://www.suse.com/documentation/sles11/

–
Kevin Boyle - Knowledge Partner
If you find this post helpful and are using the web interface,
show your appreciation and click on the star below…