[evan@ehoffman 10:35:50 ~]$ ldapsearch -x -LLL -D "ldapuser@example.com" -w password -b "OU=Users,DC=example,DC=com" -s sub -H ldaps://activedirectory.example.com "(sn=hoffman)" cn mail displayName samaccountname
dn: CN=Evan Hoffman,OU=Tech,OU=Users,DC=example,DC=com
cn: Evan Hoffman
displayName: Evan D. Hoffman
sAMAccountName: ehoffman
mail: Evan.Hoffman@example.com

The new OWA has a zillion other awesome features, my favorite being that Firefox and Chrome are no longer second-class-citizens and can use the “full version” now, even on Linux. So anyway, I guess all my work was for nothing. Not the first time (or the last).

EmailSizeByDepartment.vbs

(Edited 5/14/2010 to replace the inlined Perl script with a link to the script as a text file.)

changeadpasswd.pl

With that piece of the puzzle largely solved, I moved on to another: how will users change their passwords (which are all stored in Active Directory)? For users running Windows this is pretty trivial — they can do it right in Windows when they’re logged into the domain. But what about Linux users? I figured the easiest thing to do would be to make a web form to do this. The user would login (with the http/LDAP auth I previously setup) and the form would ask for their password (twice) and update it in Active Directory. Sounds pretty simple to me. I think if this were OpenLDAP it probably would be, but being AD, it’s not.

I’d already spent an hour or two writing the script (in PHP) when I was able to test its basic functionality. What I got was this:

Warning: ldap_mod_replace() [function.ldap-mod-replace]: Modify: Insufficient access in /home/evan/public_html/authtest/index.php

After some hair pulling I realized that I was binding with my “dummy” user when attempting to change the password. I figured the solution would be to re-bind as the user whose password I was attempting to change, which is what I did. I verified that the new bind worked, but I still couldn’t change the password. I decided to fall back to command line and started issuing some ldapmodify commands to see what I could and couldn’t do as the user. For whatever reason, it appears that even though the user CAN change his password in AD (the “user cannot change password” setting is NOT selected — I checked), the user cannot change his password through LDAP.


$ ldapmodify -vv -x -d8 -D "CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com" -w secret -H ldaps://activedirectory.example.com -f bfett.ldif
ldap_initialize( ldaps://activedirectory.example.com )
TLS certificate verification: Error, unable to get local issuer certificate
request done: ld 0x9dd86e8 msgid 1
replace unicodePwd:
"
modifying entry "CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com"
modify complete
request done: ld 0x9dd86e8 msgid 2
ldapmodify: Insufficient access (50)
additional info: 00000005: SecErr: DSID-031A0F44, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0


I Googled for the error code – DSID-031A0F44 – and found a couple of threads about people with the same problem, but no solutions.

The LDIF file I fed in looks like this:


dn: CN=Boba Fett,OU=Utility,OU=Users,DC=example,DC=com
changetype: modify
replace: unicodePwd
unicodePwd::IgBhAGIAYwBkAGUAZgBnAGgAIgA=
-


When I run the same command with my own DN/password for binding it works fine (though I did discover that you can assign multiple values to unicodePwd, meaning that, until I fixed it, the test user had two valid passwords, which seems like a bug on Microsoft’s part), I assume because I’m a domain admin. An “easy” out would be simply to have the script bind as a domain admin, but that means I’d be hardcoding a Domain Admin password in the script, which I’m against. I’ll have to put some more thought into this. Maybe Linux users will just have to log in to a Windows workstation to change their passwords. That’s not ideal, but it does already work.

Grr…

Update – Click the “ldap” tag below to see all the LDAP-related posts, including the solution to changing AD passwords via a browser.

In your .htaccess file:

AuthBasicProvider ldap
AuthType basic
AuthName "AD LDAP Test"
AuthLDAPURL     "ldap://activedirectory.example.com/OU=Users,DC=example,DC=com?sAMAccountName?sub?(!(userAccountControl:1.2.840.113556.1.4.803:=2))"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN ldapuser@example.com
AuthLDAPBindPassword password
Require ldap-group CN=Sysadmins,OU=Internal Groups,OU=Groups,DC=example,DC=com

The key here is this LDAP filter: (!(userAccountControl:1.2.840.113556.1.4.803:=2)). This is the bitwise “AND” of the userAccountControl field and the decimal number 2, which is Microsoft’s value for “account is disabled.” The codes are listed here: http://support.microsoft.com/kb/305144

In httpd.conf (or some other server config file – I did it in /etc/httpd/conf.d/mod_authz_ldap.conf inside the section), add this directive:

LDAPOpCacheEntries 0

This tells Apache not to cache the results of the LDAP op. If you don’t put this in there, the server will cache the result of the user’s login for whatever the TTL is, and the user will be able to login even after you disable the account (until the cache expires). There may be other ways around this issue, but this works for me.

This works pretty well so far. Now I can create a “SVN Users” group in Active Directory, put the people I want in that group, use the above method for authentication and everyone’s SVN login will be the same as their domain login. Single sign-on one step closer. Yay!

I thought to myself, well, I can just go ahead and write something that will sync AD -> OpenLDAP every 5 minutes. This would mostly work, except there’s apparently no way to retrieve the user’s password via LDAP – the field is write-only. This makes it so I could essentially clone the whole LDAP tree… except for the piece of info that would let people login, which is the only thing I want it for. This was frustrating.

I decided to explore a caching proxy. I was thinking if I could setup OpenLDAP as a caching proxy to Active Directory, and set a cache time of ~15 minutes, it would at least let me withstand a Windows reboot (it’s 2009 and I still feel like any Windows fix begins and ends with a reboot). I figured I’d start with a regular proxy first. This turned out to be relatively simple: in slapd.conf, at the bottom, add:

database ldap
suffix          "dc=example,dc=com"
uri "ldap://activedirectory.example.com"
acl-bind bindmethod=simple binddn="some user's DN" credentials=password

Restart slapd and do an ldapsearch against the new ldap server and it will relay the request to the AD server and relay the response to you.

Caching is another story. It seemed like it should be straightforward – yum install openldap-servers-overlays – but on my FC11 box, the package didn’t exist, and on my CentOS 5.4 box, openldap-servers-overlays didn’t appear to contain the pcache overlay used for caching. So I gave up on that.

I ended up shelving the whole idea for a while and just created 2 Windows AD VMs that will serve as Production AD auth boxes. I got everything configured – here’s a sample .htaccess file that queries our AD server for a user (by sAMAccountName, e.g. the “user” part of a username in the user@domain login name) and checks that the user is in the Sysadmins group:

AuthBasicProvider ldap
AuthType basic
AuthName "AD LDAP Test"
AuthLDAPURL     "ldap://activedirectory.example.com/OU=Users,DC=example,DC=com?sAMAccountName?sub"
AuthzLDAPAuthoritative On
AuthLDAPGroupAttribute member
AuthLDAPBindDN ldapuser@example.com
AuthLDAPBindPassword password
Require ldap-group CN=Sysadmins,OU=Internal Groups,OU=Groups,DC=example,DC=com

This works (I’ve modified it so it doesn’t include our real info, though). It will let the user in if their credentials are OK and if they are in the required group. What I discovered, however, is that if you go into AD and disable the user’s account, they are still allowed to log in (assuming the user is still in the account). This seemed stupid. I did some more research and discovered userAccountControl. Apparently you need to use bit masking against this attribute to determine if an account is disabled. This is as far as I’d gotten before vacation, but let me say this:

BRILLIANT, MICROSOFT!