debian ldap nss pam against active directory: I have no name!

There’s good info out there here and here on how to do this, I’m not going to repeat them.

A few notes though:

1) You do not need password syncronization installed when using Identity management for Unix (what Services for Unix is called in R2. Note that R2 x64 supports this stuff while SFU won’t install on on 2003 SP2 x64). You just need the NIS Server for Unix module and the admin tools, which is what you get if you just click Identity Management for Unix in add/remove programs under something like Active Directory something.

Interestingly I’ve been crashing another DC trying to get that working and while I’ve done this before it’d been a while and I forgot this key point: pam_ldap does NOT look for the users password in LDAP. It looks for the user in LDAP using the binddn to search, then BINDS as the user using the provided password to see if it succeeds or fails.

2) If when you log in as user ‘getent passwd’ stops providing useful information, and w, ls -l, etc can’t resolve the uid to a name, or “I have no name!” is part of your shell prompt, it’s because the pam stuff isn’t running as root and the user doesn’t have access to the right ldap bind credentials. I had rootbinddn set and passwords in /etc/*.secret which were 600. But AD doesn’t allow anonymous binds, so I had to move all this to the conf files and 644 them, setting binddn and bindpw instead of rootbinddn.

Story is that you could run nscd (name service caching daemon) as root and then hide this stuff from the user, I don’t have the time do deal with this at the moment though.

3) Changing passwords. I was getting this error at first:

Enter login(LDAP) password:
New password:
passwd: Authentication information cannot be recovered
passwd: password unchanged

Putting my “password sufficient pam_ldap.so” line before the pam_unix.so line in /etc/pam.d/common-password fixed that. Then:

LDAP password information update failed: Unknown error
00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Watching the LDAP transaction I saw that we were binding as the user (not the binddn) and sending a crypt password. I read in the man page about pam_password ad which I set and then I started getting this instead:

LDAP password information update failed: Unknown error
00002077: SvcErr: DSID-03190DC9, problem 5003 (WILL_NOT_PERFORM), data 0

Because I hadn’t set up SSL yet. turning on ‘ssl start_tls’ didn’t work but setting “ssl on” and “tls_checkpeer no” which makes it not verify the certs worked alright.

I put the certs in and tried to turn on tls_checkpeer but had failures and saw a lot of traffic that looked like “SASL GSS-API Integrity: searchResDone(15886) insufficientAccessRights (00002105: LdapErr: DSID-0C0907C9, comment: Error processing control, data 0, vece) [0 results]”. At first I assumed this was because I wasn’t running krb5. Everyone seems to set up winbind and I’m trying not to. Anyways, password changes still fail with:

LDAP password information update failed: Unknown error
0000052D: AtrErr: DSID-03190F00, #1:
0: 0000052D: DSID-03190F00, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9005a (unicodePwd)

I assumed at first this might be the “you’re not using a hard enough password” error, but it wasn’t the case.

I spent hours flipping different options trying to get tls to work without setting “tls_checkpeer no”. using tls (ldaps:// for the uri) or starttls with the “sasl_secprops maxssf=0” AD hack didn’t work. Eventually I stumbled over this and changed my ldaps:// URI from the IP address of the DC to the FQDN of the DC and now ssl works without tls_checkpeer no. !!!! Just put the hostname and IP in /etc/hosts if you care.

Unfortunately I can’t find a newer version of this kb article that describes how unicodepwd access control works in Windows 2000.

I grabbed the source with apt-get and it looks sane:

case PASSWORD_AD:
/*
* Patch from Norbert Klasen :
*
* To be able to change a password in AD via LDAP, an SSL connection
* with a cipher strength of at least 128 bit must be established.
* http://support.microsoft.com/support/kb/articles/q264/4/80.ASP
* http://support.microsoft.com/support/kb/articles/Q247/0/78.ASP
*
* The password attribute used by AD is unicodePwd. Its syntax is octect
* string. The actual value is the password surrounded by quotes in
* Unicode (LSBFirst).
*
* NT passwords can have max. 14 characters.
*
* FIXME:
* The conversion to Unicode only works if the locale is
* ISO-8859-1 (aka Latin-1) [of which ASCII is a subset].
*/

snprintf (new_password_with_quotes, sizeof (new_password_with_quotes),
“\”%s\””, new_password);
memset (new_unicode_password, 0, sizeof (new_unicode_password));
for (i = 0; i < bv_val =" new_unicode_password;" bv_len =" strlen" modv_bvals =" bvalsnew;" mod_type =" (char">conf->rootbinddn || getuid () != 0)
{
/* user must supply old password */
snprintf (old_password_with_quotes,
sizeof (old_password_with_quotes), “\”%s\””,
old_password);
memset (old_unicode_password, 0, sizeof (old_unicode_password));
for (i = 0; i < bv_val =" old_unicode_password;" bv_len =" strlen" modv_bvals =" bvalsold;" mod_type =" (char" mod_op =" LDAP_MOD_DELETE" mod_op =" LDAP_MOD_ADD" mod_op =" LDAP_MOD_REPLACE">

Interestingly, I went and added rootbinddn and the /etc/pam_ldap.secret file and when changing the password for the ldap user as root it works. Oddly it seems to keep allowing all the past passwords for a while as well. I’m going to leave it as this, as all users will be root users for now and can sudo passwd username.

4) (update) I had problems using openssl 0.9.8c-4etch1 and libnss-ldap 251-7.5etch1 on debian etch where when I turned on ssl ‘getent passwd’ wouldn’t fully return. turning ssl off (and changing the uri back to ldap:// from ldaps://) would make things fine again. Wireshark looked like the stream was getting mucked up somewhere, as the windows server was sending back duplicate acks. A consultant said this is a libnss-ldap bug, or at least that padl’s libnss-ldap stuff is pretty buggy expecially when you get beyond a basic ldap configuration. it looks like we’re headed for a full blown winbind configuration instead of libnss.

3 thoughts on “debian ldap nss pam against active directory: I have no name!

  1. Pingback: Users can’t change passwords in Active Directory using LDAPS Drija

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.