Comments on: Linux-AD Integration, Version 4 http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/ The weblog of an IT pro specializing in virtualization, storage, and servers Tue, 16 Mar 2010 15:22:07 +0000 http://wordpress.org/?v=abc hourly 1 By: erik http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-46162 erik Wed, 07 Oct 2009 20:58:40 +0000 http://blog.scottlowe.org/?p=400#comment-46162 Well, I'm 99% of the way there. :-) Thanks to your great documentation, I've been able to work through the vast majority of this process. The one last holdout is limiting access via AD group. From what I've read, this *should* just work by setting the pam_groupdn and pam_member_attribute settings in ldap.conf. Well I've tried every different permutation of these settings I can think of, and have had no luck. Hopefully someone here might be able to shed some light. Here are some (sanitized) configs: First, the easy one, nsswitch.conf: http://pastebin.com/f24823ad6 Next, pam.d/system-auth: http://pastebin.com/fe6f98df ldap.conf: http://pastebin.com/f3d94b4cc Any ideas? Thanks! Well, I’m 99% of the way there. :-)

Thanks to your great documentation, I’ve been able to work through the vast majority of this process. The one last holdout is limiting access via AD group. From what I’ve read, this *should* just work by setting the pam_groupdn and pam_member_attribute settings in ldap.conf. Well I’ve tried every different permutation of these settings I can think of, and have had no luck. Hopefully someone here might be able to shed some light.

Here are some (sanitized) configs:
First, the easy one, nsswitch.conf:
http://pastebin.com/f24823ad6

Next, pam.d/system-auth:
http://pastebin.com/fe6f98df

ldap.conf:
http://pastebin.com/f3d94b4cc

Any ideas? Thanks!

]]> By: Ryan B. Lynch http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-46026 Ryan B. Lynch Sat, 26 Sep 2009 21:31:47 +0000 http://blog.scottlowe.org/?p=400#comment-46026 Scott, I have found your AD articles to be enormously helpful, and I've based my own Linux-AD integration efforts on the work you've done. I wanted to add some notes about two topics that you don't address, in case anyone else wants to pursue them: Password changes from Linux hosts, and Kerberos-authenticated LDAP lookups. I should note that I'm working with an up-to-date version of Fedora 11 Linux (x86-64), so I may just have newer, better versions of some of the key components. Red Hat/Centos users can probably build these updated packages from the Fedora or EPEL source RPMs, if those distros don't provide them. PASSWORD CHANGING: My initial test configurations followed your examples, and 'passwd' didn't work for AD accounts, no surprise, there. On a hunch, I ran 'netstat' against my two DCs, and I noticed that one wasn't listening on port 749, at all. Port 464 (TCP) was open on both, though. I modified my '/etc/krb5.con' file, changing the 'admin_server' line to 'admin_server = dcname.domain.com:464' (note the port change, there). For reference, here's the 'password' section of my PAM 'system-auth' file, too: password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_krb5.so minimum_uid=9999 password required pam_deny.so Using the configuration, above, password changes work flawlessly. I even get the right error messages back when a new password doesn't meet the domain password complexity requirements. (Also, I'll note that the 'kpasswd' command works, too. It doesn't integrate with PAM, at all, so it's a nice backup in case of pam_krb5 problems, and the password change process is basically identical--run 'kpasswd', input current password, and then input the new password twice.) SASL (KRB4) AUTH FOR LDAP LOOKUPS: I have some security concerns with using non-SSL simple LDAP binds for group/user name resolution. Since nss_ldap has Kerb auth support (via SASL), I decided to make the switch. (SSL support may be coming a little later, if I can coordinate the CA setup process with our Windows admins.) The result isn't perfect, but I think it's a good start. Basically, I've replaced the domain-wide LDAP "bind" user account. Now, each Linux machine now uses its own AD machine account ('HOSTNAME$@DOMAIN.COM'), the creds for which were added to our private, protected '/etc/krb5.keytab' file by the 'net ads join' command. (You should be able to confirm this by running 'klist -k' as root.) In my '/etc/ldap.conf' file, I removed all of these directives: host 10.10.10.10 base dc=example,dc=com uri ldap://server.example.com/ binddn ldap@example.com bindpw adldapbindpw with these directives, instead: nss_srv_domain domain.com bind_timelimit 5 timelimit 15 idle_timelimit 1800 bind_policy soft nss_reconnect_tries 3 krb5_ccname FILE:/tmp/krb5cc_nss_ldap use_sasl on rootuse_sasl yes sasl_authid HOSTNAME$ rootsasl_auth_id HOSTNAME$ sasl_secprops maxssf=0 This tells nss_ldap to look up the LDAP SRV records in the 'domain.com' domain, and to connect to whatever LDAP service(s) it finds there, in the DNS. nss_ldap will also look for Kerberos tickets in the cache file '/tmp/krb5cc_nss_ldap' (which will need to be created and made world-readable by another process) and to connect using any tickets for the principal 'HOSTNAME$'. (I'll leave it to others to look up what the rest of those directives do.) To populate and manage that world-readable ticket cache, I made a script '/etc/init.d/krb5_nss_ldap' that can handle the 'kinit' and 'kdestroy' logic needed to create, refresh, and destroy the ticket cache. It runs as a chkconfig service at boot time, with root privs, so it can access the keytab for the creds needed to obtain the TGT that it writes into the '/tmp/' cache. I run that same script from a Cron job on an hourly basis, as well, to keep the cached TGT from expiring. So the idea, here, is that any low-privilege process needing an LDAP lookup will try to use the system's own computer account tickets, which should be available in a cache that any low-privilege process can access. But none of these low-privilege processes have access to the system keytab file '/etc/krb5.keytab'. The security difference isn't huge, here: A rogue process (say, an attacker with a local nonroot exploit) could still use the system TGT to muck around in AD and do some damage. The real benefits are in the aftermath of an attack: - The machine account, itself, hasn't been comprised. Once the attacker is kicked out, he can only use the stolen TGT until it expires (in less than 2 hours, if you used the same kinit parameters as me). - You don't have to replace compromised LDAP bind account creds on all your Linux machines. (This is also kind of nice, beforehand--you can auto-generate all the 'ldap.conf' parameters, locally, using a script that grabs the local host and domain names.) I intend to change this, slightly, in production use. I haven't fully considered the potential security risks in making the computer account creds available generally, but I suspect it's not really a secure practice. I'm planning to auto-generate a separate 'service'-type principal for each machine, for LDAP usage, only. But the rest of the process should be the same. With SSL enabled, and incorporating my planned change, I wonder whether it's possible to secure things even further. I believe the 'nscd' daemon might be able to handle the entire LDAP bind-and-lookup process by itself, which would mean that no other accounts would need direct LDAP access--'nscd' would be a trusted intermediary. But I don't know whether 'nscd' can handle all of the needs of local processes, so it might be a little more complicated than that. Scott, I have found your AD articles to be enormously helpful, and I’ve based my own Linux-AD integration efforts on the work you’ve done. I wanted to add some notes about two topics that you don’t address, in case anyone else wants to pursue them: Password changes from Linux hosts, and Kerberos-authenticated LDAP lookups.

I should note that I’m working with an up-to-date version of Fedora 11 Linux (x86-64), so I may just have newer, better versions of some of the key components. Red Hat/Centos users can probably build these updated packages from the Fedora or EPEL source RPMs, if those distros don’t provide them.

PASSWORD CHANGING:

My initial test configurations followed your examples, and ‘passwd’ didn’t work for AD accounts, no surprise, there. On a hunch, I ran ‘netstat’ against my two DCs, and I noticed that one wasn’t listening on port 749, at all. Port 464 (TCP) was open on both, though.

I modified my ‘/etc/krb5.con’ file, changing the ‘admin_server’ line to ‘admin_server = dcname.domain.com:464′ (note the port change, there). For reference, here’s the ‘password’ section of my PAM ’system-auth’ file, too:

password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so minimum_uid=9999
password required pam_deny.so

Using the configuration, above, password changes work flawlessly. I even get the right error messages back when a new password doesn’t meet the domain password complexity requirements.

(Also, I’ll note that the ‘kpasswd’ command works, too. It doesn’t integrate with PAM, at all, so it’s a nice backup in case of pam_krb5 problems, and the password change process is basically identical–run ‘kpasswd’, input current password, and then input the new password twice.)

SASL (KRB4) AUTH FOR LDAP LOOKUPS:

I have some security concerns with using non-SSL simple LDAP binds for group/user name resolution. Since nss_ldap has Kerb auth support (via SASL), I decided to make the switch. (SSL support may be coming a little later, if I can coordinate the CA setup process with our Windows admins.) The result isn’t perfect, but I think it’s a good start.

Basically, I’ve replaced the domain-wide LDAP “bind” user account. Now, each Linux machine now uses its own AD machine account (’HOSTNAME$@DOMAIN.COM’), the creds for which were added to our private, protected ‘/etc/krb5.keytab’ file by the ‘net ads join’ command. (You should be able to confirm this by running ‘klist -k’ as root.)

In my ‘/etc/ldap.conf’ file, I removed all of these directives:

host 10.10.10.10
base dc=example,dc=com
uri ldap://server.example.com/
binddn ldap@example.com
bindpw adldapbindpw

with these directives, instead:

nss_srv_domain domain.com
bind_timelimit 5
timelimit 15
idle_timelimit 1800
bind_policy soft
nss_reconnect_tries 3
krb5_ccname FILE:/tmp/krb5cc_nss_ldap
use_sasl on
rootuse_sasl yes
sasl_authid HOSTNAME$
rootsasl_auth_id HOSTNAME$
sasl_secprops maxssf=0

This tells nss_ldap to look up the LDAP SRV records in the ‘domain.com’ domain, and to connect to whatever LDAP service(s) it finds there, in the DNS. nss_ldap will also look for Kerberos tickets in the cache file ‘/tmp/krb5cc_nss_ldap’ (which will need to be created and made world-readable by another process) and to connect using any tickets for the principal ‘HOSTNAME$’. (I’ll leave it to others to look up what the rest of those directives do.)

To populate and manage that world-readable ticket cache, I made a script ‘/etc/init.d/krb5_nss_ldap’ that can handle the ‘kinit’ and ‘kdestroy’ logic needed to create, refresh, and destroy the ticket cache. It runs as a chkconfig service at boot time, with root privs, so it can access the keytab for the creds needed to obtain the TGT that it writes into the ‘/tmp/’ cache. I run that same script from a Cron job on an hourly basis, as well, to keep the cached TGT from expiring.

So the idea, here, is that any low-privilege process needing an LDAP lookup will try to use the system’s own computer account tickets, which should be available in a cache that any low-privilege process can access. But none of these low-privilege processes have access to the system keytab file ‘/etc/krb5.keytab’.

The security difference isn’t huge, here: A rogue process (say, an attacker with a local nonroot exploit) could still use the system TGT to muck around in AD and do some damage. The real benefits are in the aftermath of an attack:

- The machine account, itself, hasn’t been comprised. Once the attacker is kicked out, he can only use the stolen TGT until it expires (in less than 2 hours, if you used the same kinit parameters as me).

- You don’t have to replace compromised LDAP bind account creds on all your Linux machines. (This is also kind of nice, beforehand–you can auto-generate all the ‘ldap.conf’ parameters, locally, using a script that grabs the local host and domain names.)

I intend to change this, slightly, in production use. I haven’t fully considered the potential security risks in making the computer account creds available generally, but I suspect it’s not really a secure practice. I’m planning to auto-generate a separate ’service’-type principal for each machine, for LDAP usage, only. But the rest of the process should be the same.

With SSL enabled, and incorporating my planned change, I wonder whether it’s possible to secure things even further. I believe the ‘nscd’ daemon might be able to handle the entire LDAP bind-and-lookup process by itself, which would mean that no other accounts would need direct LDAP access–’nscd’ would be a trusted intermediary. But I don’t know whether ‘nscd’ can handle all of the needs of local processes, so it might be a little more complicated than that.

]]> By: Tim http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-45371 Tim Wed, 05 Aug 2009 16:47:25 +0000 http://blog.scottlowe.org/?p=400#comment-45371 Scott - you can ignore my post. The authentication shows up under user "System", which initially thew me off. Now to get the password change to work. I'm sure the rejection is due to a policy somewhere. Thanks! Scott - you can ignore my post. The authentication shows up under user “System”, which initially thew me off.

Now to get the password change to work. I’m sure the rejection is due to a policy somewhere.

Thanks!

]]> By: Tim http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-45361 Tim Tue, 04 Aug 2009 20:52:22 +0000 http://blog.scottlowe.org/?p=400#comment-45361 Scott, I've used your methodology to successfully implement LDAP authentication between Linux and Windows, using kerberos. The industry that I work in has a lot of gov security requirements, one of which being every login to a windows box must be recorded in the event viewer. I'm using Win2k3 R2 SP2. The only account that shows up in the security event viewer is the binder account. How do I get the user account to show up in the Win2k3 security log as well? Thanks, Tim Scott,

I’ve used your methodology to successfully implement LDAP authentication between Linux and Windows, using kerberos. The industry that I work in has a lot of gov security requirements, one of which being every login to a windows box must be recorded in the event viewer. I’m using Win2k3 R2 SP2. The only account that shows up in the security event viewer is the binder account. How do I get the user account to show up in the Win2k3 security log as well?

Thanks,
Tim

]]> By: slowe http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-44351 slowe Thu, 30 Apr 2009 03:18:34 +0000 http://blog.scottlowe.org/?p=400#comment-44351 Kathy, Without knowing more about your installation and your specific configuration, there isn't a whole lot I can do to help. Kathy,

Without knowing more about your installation and your specific configuration, there isn’t a whole lot I can do to help.

]]> By: kathy http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-44345 kathy Wed, 29 Apr 2009 18:00:29 +0000 http://blog.scottlowe.org/?p=400#comment-44345 Hi I have server running Red Hat Enterprise Linux ES release 4 (Nahant Update 6). we have ldap configured on it, here is several problems that we have encountered and i'm wondering if anyone else has seen them: 1. doing the following causes segmentation fault. #getent -s 'dns ldap' passwd Segmentation fault 2. using sudo gets the followign error: #sudo getent passwd Password: sudo: ../../../libraries/liblber/sockbuf.c:90: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)' failed. Aborted any comments is appreciated. regards, Kathy Hi
I have server running Red Hat Enterprise Linux ES release 4 (Nahant Update 6). we have ldap configured on it, here is several problems that we have encountered and i’m wondering if anyone else has seen them:

1. doing the following causes segmentation fault.
#getent -s ‘dns ldap’ passwd
Segmentation fault

2. using sudo gets the followign error:
#sudo getent passwd
Password:
sudo: ../../../libraries/liblber/sockbuf.c:90: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)’ failed.
Aborted

any comments is appreciated.

regards,
Kathy

]]> By: Patrick http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-44210 Patrick Sun, 12 Apr 2009 05:10:06 +0000 http://blog.scottlowe.org/?p=400#comment-44210 @Munroe I don't think you want/need nscd. i'm not sure about why it keeps reconnecting to the ldap server... @Munroe

I don’t think you want/need nscd.
i’m not sure about why it keeps reconnecting to the ldap server…

]]> By: Sleepy http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-43661 Sleepy Thu, 19 Feb 2009 03:12:43 +0000 http://blog.scottlowe.org/?p=400#comment-43661 Scott, Thanks so much for this guide! I have found it really really useful. I thought I would add a tip that I worked out.... In our AD we have all our Linux user accounts in an OU which is in another OU. The time it took to to log in after entering a password was too long. Like 10-15 seconds. So, in /etc/ldap.conf I changed these lines like this: nss_base_passwd ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub nss_base_shadow ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub nss_base_group ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub?&(objectCategory=group)(gidnumber=*) And this fixed it. Log in time after this was about 2 seconds. I did have "pam_login_attribute sAMAccountName" set too but it made no difference. Cheers! Scott,
Thanks so much for this guide! I have found it really really useful.
I thought I would add a tip that I worked out….
In our AD we have all our Linux user accounts in an OU which is in another OU. The time it took to to log in after entering a password was too long. Like 10-15 seconds. So, in /etc/ldap.conf I changed these lines like this:
nss_base_passwd ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub
nss_base_shadow ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub
nss_base_group ou=ou1,dc=test,dc=domain,dc=co,dc=uk?sub?&(objectCategory=group)(gidnumber=*)
And this fixed it. Log in time after this was about 2 seconds. I did have “pam_login_attribute sAMAccountName” set too but it made no difference.
Cheers!

]]> By: Munroe http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-41969 Munroe Thu, 16 Oct 2008 06:44:36 +0000 http://blog.scottlowe.org/?p=400#comment-41969 Great article. I have been successful binding a Debian Lenny Box to AD w2k3 R2. However for some reason performance is less than stellar. We are using this box as a mail server. and my auth.log is riddled with: Oct 16 02:24:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt Oct 16 02:25:37 krypton imaplogin: nss_ldap: could not connect to any LDAP server as cn=binder,ou=test,dc=ad,dc=harmony,dc=lan - Can't contact LDAP server Oct 16 02:25:37 krypton imaplogin: nss_ldap: failed to bind to LDAP server ldap://=: Can't contact LDAP server Oct 16 02:25:37 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 Oct 16 02:25:37 krypton imaplogin: nss_ldap: reconnecting to LDAP server... Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnecting to LDAP server... Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt I have found that nscd is also causing lots of performance problems. I'm wondering if anyone else has these issues? Great article. I have been successful binding a Debian Lenny Box to AD w2k3 R2. However for some reason performance is less than stellar. We are using this box as a mail server. and my auth.log is riddled with:

Oct 16 02:24:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt
Oct 16 02:25:37 krypton imaplogin: nss_ldap: could not connect to any LDAP server as cn=binder,ou=test,dc=ad,dc=harmony,dc=lan - Can’t contact LDAP server
Oct 16 02:25:37 krypton imaplogin: nss_ldap: failed to bind to LDAP server ldap://=: Can’t contact LDAP server
Oct 16 02:25:37 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254
Oct 16 02:25:37 krypton imaplogin: nss_ldap: reconnecting to LDAP server…
Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt
Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnecting to LDAP server…
Oct 16 02:25:38 krypton imaplogin: nss_ldap: reconnected to LDAP server ldap://192.168.90.254 after 1 attempt

I have found that nscd is also causing lots of performance problems. I’m wondering if anyone else has these issues?

]]> By: John Zivkovic http://blog.scottlowe.org/2007/01/15/linux-ad-integration-version-4/comment-page-4/#comment-41961 John Zivkovic Wed, 15 Oct 2008 23:44:11 +0000 http://blog.scottlowe.org/?p=400#comment-41961 Hi Scott, Excellent post! I have used your instructions as the basis for our Centos 5.2 / 2k3R2 SSO solution and it works like a charm. We do not actually join the linux clients to our domain. I vaguely remember you toying with this idea in one of your posts, but I cannot find the information. Just interested in the significance of this step? We have a samba server (serving home directories) that I have joined to the AD so that winbind can perform the appropriate mappings (Note: idmap backend = ad works very well), but I don't understand the need to join for our Centos 5.2 workstations (clients). Regards, John Zivkovic Hi Scott,

Excellent post!

I have used your instructions as the basis for our Centos 5.2 / 2k3R2 SSO solution and it works like a charm.

We do not actually join the linux clients to our domain. I vaguely remember you toying with this idea in one of your posts, but I cannot find the information. Just interested in the significance of this step?

We have a samba server (serving home directories) that I have joined to the AD so that winbind can perform the appropriate mappings (Note: idmap backend = ad works very well), but I don’t understand the need to join for our Centos 5.2 workstations (clients).

Regards,

John Zivkovic

]]>