a blog about unixy stuff and so on
2009/07/10Using Active Directory as an LDAP server for unix
Using AD as an ldapserver is quite usefull, as you do not need to manage users on all hosts, nor do you need to configure printers, groups etc in more than one place. It also allows for central authentication for all users, ie, they have the same password in unix and windows. It is recommended that you use kerberos instead of ldap for autentication however.Sometimes there are reasons to just go with ldap, and not involve kerberos at all. This is usually the case when you are working in a nonfunctional organization where it is impossible for the unix admins to gain help from windows admins etc. Kerberos requires some fiddling with keytabs. More on that in a later post.
To get started, you first need to install services for unix on one ad-server. The installation forces a reboot, so keep that in mind when selecting the dc. The installation defaults are ok, as they do not start any services on the ad-server, except for the nfs client which can be disabled after installation. You can find sfu as a free download from MS here:
Once sfu is installed and the server is rebooted, you will have a new tab called unix attributes in active directory users and computers. Now we can start adding users that are needed for solaris. The first step is to create a proxy users that solaris will utilize to make ldap queries. Create a user that is a member of the "domain guests" security group. It does not need any more memberships.
Disable password expiration and enable that the user can not change his password. Be sure to remember the password. The boring windows-stuff is now completed and we can move on to confiugre solaris. The solaris version we are targeting is solaris 10. Note that solaris pre update 6 is quite buggy when it comes to ldap, so you might want to patch it up a bit before starting to play around with ldap.
First, start by editing /etc/nsswitch.ldap. This file will later overwrite nsswitch.conf when you start the ldapclient command. A good idea is to only use ldap for passwd and group entries. if you use the defaults, DNS will stop working, and a lot of stuff will be slower than neccessary.
here is an example of a nsswitch.ldap file that is basically a standard nsswitch.conf copied to nsswitch.ldap and then tweaked a bit.
bash-3.00# grep ldap /etc/nsswitch.ldap passwd: files ldap group: files ldap printers: user files ldap
The next step is to initialize the ldap client. This is a basic config that probably will work if you change romab domains for your own, but note that we are using simple binds here, which IS A BAD IDEA as passwords are sent in plain text to the ldap server.
ldapclient manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN=cn=proxyusr,cn=Users,dc=research,dc=romab,dc=com \ -a proxyPassword=yourpassword \ -a defaultSearchBase=dc=research,dc=romab,dc=com \ -a domainName=research.romab.com \ -a defaultServerList=10.200.2.3 \ -a attributeMap=group:userpassword=msSFU30Password \ -a attributeMap=group:memberuid=msSFU30MemberUid \ -a attributeMap=group:gidnumber=msSFU30GidNumber \ -a attributeMap=passwd:gecos=msSFU30Gecos \ -a attributeMap=passwd:gidnumber=msSFU30GidNumber \ -a attributeMap=passwd:uidnumber=msSFU30UidNumber \ -a attributeMap=passwd:uid=sAMAccountName \ -a attributeMap=passwd:homedirectory=msSFU30HomeDirectory \ -a attributeMap=passwd:loginshell=msSFU30LoginShell \ -a attributeMap=shadow:shadowflag=msSFU30ShadowFlag \ -a attributeMap=shadow:userpassword=msSFU30Password \ -a attributeMap=shadow:uid=sAMAccountName \ -a objectClassMap=group:posixGroup=group \ -a objectClassMap=passwd:posixAccount=user \ -a objectClassMap=shadow:shadowAccount=user \ -a serviceSearchDescriptor=passwd:cn=Users,dc=research,dc=romab,dc=com?sub \ -a serviceSearchDescriptor=group:cn=groups,dc=research,dc=romab,dc=com?sub
Does it work? A good test is to do a getent passwd username and see if the user appears correctly.
bash-3.00# grep andreas /etc/passwd bash-3.00# getent passwd andreas andreas:x:10000:2500::/export/home/andreas:/bin/sh
If that whent well, you only need to configure pam to start being able to log in with users configured in your active directory. Here is a sample pam configuration that you might want to use:
/etc/pam.conf: other auth required pam_unix_auth.so.1 server_policy other auth required pam_ldap.so.1
This enables pam authentication for ssh. If you need it for login, simply change the login directives as above.
/etc/pam.conf: login auth required pam_unix_auth.so.1 server_policy login auth required pam_ldap.so.1
This configuration has several security issues. Passwords are sent in clear text from the client(sol10) to the server(AD) so all users passwords will be exposed. This can however be fixed by using TLS:simple instead of a regular simple bind. It Also have the problem of the data being replied from the server can be manipulated in transit, which means that if we use solaris RBAC feature stored in the LDAP, additional roles may be added, or the uid number may be manipulated. Using TLS is a must if you are intending to use this.
Also note that the uid attribute is not indexed by the default SFU installation. For performance reasons, you might want to add this via the active directory schema snap-in. If it is not visible as an available snap-in, start cmd.exe and type "regsrv32 schmmgmt.dll" and it should become visible in the mmc.
There are several security considerations with this configuration. Besides not using TLS, the most noteable problem is that pam_ldap.so.1 in solaris ONLY handles authentication, there is no way that you can group users so that only certain user may log in to server X while other are allowed to server Y. A better approach is to use padls pam_ldap, which offers a lot more options. The best way is probably to use the combination of solaris nss_ldap, pam_ldap from padl and then use kerberos for autentication. It will give you centralized autentication and authorization, and will not send any passwords over the wire except when the proxy user binds, and when a users uses su. The su problem can be mitigated with kerberos aswell, but a compromised server will expose the principals password if su is used.