These are the steps I followed, your mileage may vary..

1). Verify Windows2008R2 isn’t using a cert already…

Windows 2008R2 should be listening already on port 636, but there will be NO cert attached. To confirm this..use the openssl s_client which I’ve been abusing lately..

Running that command on a default Windows 2008 AD box will come up with no certificates.

So after you install the cert, and reboot your Windows AD box, you should run the above command again from a Linux host and you should see the server certs at this stage.
Don’t be concerned with the last line, which probably should say something like “Verify return code: 21 (Unable to verify the first certificate)” We are just verifying that there is a cert attached to the AD host at this point.

2). LDAP Bind account

Setup an LDAP Bind account in Active Directory, this account doesn’t need to have any special privileges on the account.  In fact, just granting guest privs will work. This account will be needed to be configured into every /etc/ldap.conf file and this is required as it’s really not a good idea to turn on anonymous on the AD host.

3).  Install Identity Management for UNIX on your AD host.

This primarily is needed for the extra tab provided in user properties (UNIX tab).  This grants home directory, UID, GID etc POSIX functionality.  By default all AD users will NOT have UNIX access, this is something we need to turn on.

4).  Group accounts.

Create a separate OU for all the UNIX groups.  For my setup, I choose to not use the pre-existing Windows groups.  That might be an easier approach for you, however, we used to use Novell Edirectory / OpenLDAP solution so all our Linux boxes are  all ready setup for that  and are pre-populated with those groups.   Basically I just mirrored current group names and users in those groups which I created in AD to help minimize to many configuration changes on every Linux host.

My base group OU = ou=unix,ou=group accounts,dc=example,dc=com

And in AD, just create a new folder called Unix under “group accounts”.

You will want to create a new group called unixusers or whatever you want.  This group will be used for the primary UNIX group, most users will also be part of other groups, but if they have UNIX enabled onto there accounts, then they should be part of unixgroup account for sure.

You need to make sure that you enable the users accounts first by granting a UID, home directory etc FIRST, before you goto try to populate that user in the groups.  To populate users in the group, just double click whatever group, two places Members & UNIX Attributes tab.  I used to think only the UNIX attribute tab was necessary, until I tried to go get Apache logins working then noticed that uses the Members tab.  Anyhow  UNIX tab, make sure NIS Domain: has whatever name in there selected and group ID will auto update to the next available GID, if it’s NOT the first group your setting up.  Then just Add, select what users, click ok, then click Members tab, advanced, find now, select users , rinse and repeat as deemed necessary.  Ok all the way out.

5).  User accounts

To turn on the UNIX access on a user account, just find your user , right click, properties, and you should see a new tab called “Unix Attributes”

Here’ you will see NIS Domain:  drop down that to your NIS name (which you named in the Identity Manager for UNIX)

UID:  21000 (use whatever fits for your orgization)

Shell: /bin/bash

Home Directory:  /home/username

Prmary Group:  unixusers

 

A very important thing here:   PLease make sure ALL letters are in lower-case.   For Windows of course, it really doesn’t matter, but for UNIX which is case sensitive it matters.  Some of the default entries are in both uppper /lower case, just change it to lower case.  Does anyone knows how to change the default values on this, so its’ always lower case?  I’ll write more on this later as there are some interesting things with /etc/sudoers, PAM w/ makehomedir.so settings.  If you just want to save yourself some headaches later down the road, also click on Account tab and change User logon name to all lower case and preWindows2000 to all lowercase, and click Ok.

Tools like getent, id are pulling from this Account tab settings and so far I haven’t been able to locate anything (short of just recompiling those tools, which I wasnt going to do) that I can setup so it ignores case and just uses all lower case.   Maybe a wrapper would work..I don’t know.  If someone knows, let me know.

 

6). Installing cacert.pem

You should have gotten a CA-Cert file along with your AD SSL cert.  Your can place this cert anywhere,  I placed mine in /etc/openldap/keys

Copy cacert.pem into /etc/openldap/keys

Create a hash of this file, using

To verify this cacert.pem will work, you can use the following command to test

openssl s_client -connect windowsAD.example.com:636 -CAfile /etc/openldap/keys/cacert.pem

If this openssl client does NOT work, save yourself sometime and double check to make sure you have the correct cacert. We have multiple CA’s at my work and for last few hours I’ve been struggling trying to get this working.. turns out I was using the wrong cacert.

Quickly check it by running this command:
openssl x509 -in cacert.pem -noout -text

Once that is working then try using this ldapsearch -ZZ , this will test out you AD Bind user account as well as the SSL cert.

If you don’t know what the -D part is log onto the Windows host, open a command prompt (cmd.exe) type:

That should spit out the correct DN. Maybe there is an easier way, but I know I struggled with this part for a long time before finding that command.
-Z turns on TLS for the ldapsearch, -ZZ and important that you use this as if AD returns an error you will see if otherwise you won’t , it’s very important there is no error.  Make sure you do ldap, and not ldaps, TLS uses port 389 and SSL or ldaps uses port 636

It’s very important to make sure the last line on this return comes back with (ok) line.  ( Verify return code: 0 (ok) ).  If it doesn’t then you need to verify you have the correct cacert, because if it doesn’t work here, it’s definitely not going to work after we setup everything.

 

7).  /etc/openldap/ldap.conf   and /etc/ldap.conf

First of all these two files are different but both are needed and will need to be edited.

/etc/openldap/ldap.conf:   this file is basically used for using the OpenLDAP tools like ldapsearch, ldapmodify etc.

/etc/ldap.conf:  this is the NSS LDAP client configuration file.  This is what PAM will be using.

 

 

host:  Make sure you are using a fqdn here.  We used to use IP only here, as I didn’t want to have a DNS fqdn there and thought IP would just be better, it’s not.  You will get alot of bind errors in the logs when it’s an IP,  I ended up just adding the host to /etc/hosts so this way if DNS did mess up , we could still log in.   Update:  It’ 100% doesn’t work when you trying to use SSL or TLS, using just the IP.  We used to use non secure method and using IP gives a ton of bind errrors but it still works.

uri:  samething make sure it’s fqdn

binddn/bindpw:  The guest user account that you setup

ssl:  you can also have “on” here, but if you did you need to update uri line to ldaps…  and comment out all the tls_ lines

nss_base_group:  you can just leave dc=example,dc=com like the above user groups, but it’s faster if you choose the exact path so you don’t have to search through all the Windows groups first.  If you are un-sure what the OU path is, open command prompt on the AD host

I’m sure there are easier ways, but that’s how I did it.

bind_policy soft:  make sure you have this, or without it , the next time you go to reboot, it probably will get hung.

8).  nsswitch.conf & PAM

Here’s ours, using just “files ldap” should be just fine for passwd, group

 

9)  /etc/pam.d

SLES handles the pam files a little bit different instead of having everything in one file like Redhat flavors, SLES breaks them out into 4 files.  I personally like Redhat’s method alot better , but whatever .

To make the Linux hosts accept for only certain AD groups, and it be able to use multiple groups , we use /etc/security/access.conf.   The pam_access.so is enforcing this.  Common-session will automatically create  users home directory on the system if they didn’t already have one.  Again, your setup may be different…

 

Once everything above has been installed, you can go ahead and try it.  I highly recommend you don’t log out 100%, leave one ssh session , ie the session your using logged in.  And just open a new sesssion to test, this way you can make adjustments when it doesn’t work and won’t be shut out..lol

getent passwd

getent group

id username

new session:  make sure you populate /etc/security/access.conf with your users or you won’t be able to log in.  Or just for now, comment #-ALL:ALL until you get everything working.

I highly recommend once you are able to SSH in, that you setup a sniffer to make sure you see TLS/SSL traffic and obviously no passwords in plain text…

 

You may find it necessary to dump your nscd cache if you are in fact using this.

sudo nscd-ihosts; nscd -i passwd; nscd -i group; /etc/init.d/nscd restart