Linux-AD Integration With Windows Server 2003 R2

UPDATE:  An updated version of these instructions has been posted.

The integration of (what was formerly called) Services for UNIX into Windows Server 2003 R2 also brought some other changes.  To accommodate those changes, I’ve updated my Linux-AD integration instructions (the previous instructions are here for pre-R2 versions of Windows).  If you need to integrate Linux systems for authentication into Active Directory with Windows Server 2003 R2, these instructions should get you there.

Overall, the instructions are very similar to the instructions for pre-R2 versions of Windows.

Preparing Active Directory (One-Time)

Based on what I’ve seen so far, it appears as if a partial RFC 2307-compliant schema is included by default with Windows Server 2003 R2.  This means that it is no longer necessary to extend the schema to include attributes such as uid, gid, login shell, etc.  However, while the schema does appear to be present by default, you must install the “Server for NIS” component on at least one domain controller in order to be able to actually set those attributes (and it will be necessary to set the attributes before logins from Linux will work).

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.  Installing the “Server for NIS” component enables this, as mentioned previously.

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.

Preparing Active Directory (Each Server)

For each Linux-based server that will be authenticating against Active Directory, follow the steps below.

  1. Create a computer account in Active Directory.  When creating the computer account, be sure to specify that this account may be used by a pre-Windows 2000–based computer.
  2. Use the following command at a command prompt to configure the new computer account:
    ktpass -princ host/fqdn@REALM -mapuser DOMAIN\name$
    -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
    -out filename

    Of course, you’ll need to substitute the appropriate values for “fqdn” (the fully-qualified domain name of the computer), “REALM” (the DNS name of your Active Directory domain in UPPERCASE), “DOMAIN” (the NetBIOS name of your Active Directory domain), “password” (the password that will be set for the new computer account), and “filename” (the keytab that will be generated and must be copied over to the Linux computer).

If you need to rebuild the Linux server for whatever reason, you’ll need to delete the computer account you created and repeat this process.

Preparing Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

  1. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
  2. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.
  3. Edit the krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:
    [logging]
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
     default_realm = EXAMPLE.COM
     dns_lookup_realm = true
     dns_lookup_kdc = true
    
    [realms]
     EXAMPLE.COM = {
      kdc = host.example.com:88
      admin_server = host.example.com:749
      default_domain = example.com
     }
    
    [domain_realm]
     .example.com = EXAMPLE.COM
     example.com = EXAMPLE.COM
    
    [kdc]
     profile = /var/kerberos/krb5kdc/kdc.conf
    
    [appdefaults]
     pam = {
       debug = false
       ticket_lifetime = 36000
       renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
     }
  4. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.
    host 10.10.10.10
    base dc=example,dc=com
    uri ldap://server.example.com/
    binddn [email protected]
    bindpw adldapbindpw
    scope sub
    ssl no
    nss_base_passwd dc=example,dc=com?sub
    nss_base_shadow dc=example,dc=com?sub
    nss_base_group dc=example,dc=com?sub
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos name
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member
  5. Securely copy the file created using the ktpass.exe utility above to the Linux server in question, placing it in the /etc directory as krb5.keytab.  (SFTP or SCP are excellent candidates for this.)
  6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.
  7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

That should be it.  Once you do that, you should be able to use kinit from a Linux shell prompt (for example, “kinit aduser”) and generate a valid Kerberos ticket for the specified Active Directory account.

At this point, any PAM-aware service that is configured to use the stacked system file (such as the system-auth configuration on Red Hat-based distributions) will use Active Directory for authentication.  Note, however, that unless you also add the pam_mkhomedir.so module in the PAM configuration, home directories will have to be created manually for any Active Directory account that may log on to that server.  (I generally recommend the use of pam_mkhomedir.so in this situation.)

This configuration was tested on Red Hat Linux 9.0 as well as CentOS 4.3.

Tags: , , , , , , , ,

43 comments

  1. Scott’s avatar

    I tried to follow the above guide but have failed somewhere.

    With the ktpass utility I have a few questions:
    fqdn = fqdn of the machine account that you added to AD?
    name$ is that a variable or is that a constant?

    Can you show a complete example?

    Can you show the output from ktpass?

    Although I can kinit user, I get these errors in /var/log/messages when trying too ssh to Linux server using credentials of AD user.

    pam_krb5[3179]: error resolving user name ‘test’ to uid/gid pair
    pam_krb5[3179]: error getting information about ‘test’

    I have seen other guides do the following with keytab file:

    ktutil
    rkt
    list
    wkt /etc/krb5.keytab
    q

    Is the above used if you have multiple machines you are trying to integrate into AD. In your guide you copy the file created on Windows server directly to /etc/krb5.keytab on Linux server. What if you have multiple Linux machines that need to be integrated?

    In my case, it appears LDAP is making a connection and finding the correct user, but I get the following error in /var/log/messages when trying to ssh to Linux box using AD credentials:

    pam_ldap: error trying to bind as user “CN=,OU=,OU=,DC=domain,DC=net” (Invalid credentials)

    The CN from above is the full common name (cn) and not msSFU30Name, sAmAccountName or uid. Is this correct? I am using logon account name when trying to ssh to Linux server and the logon account name is not the same as “cn” which is the Full Name of the user.

    Any suggestions for what I might be doing wrong?

    Also, any tips for adding SSL/TLS and SASL with this guide?

  2. Scott’s avatar

    Anything that used “” angle brackets in the message above is invisible. I assume due to being interpreted as HTML tags.

    after rkt should be the name of the keytab file that was copied from Windows server to Linux server.

    In the pam_ldap error the correct information from AD is returned for CN, OU, and DC.

    Thanks.
    Scott

  3. slowe’s avatar

    Scott,

    With regards to ktpass, a sample command would be something like this (for a Linux server called LINSERV01 with an FQDN of linserv01.domain.com):

    ktpass -princ host/[email protected] -mapuser DOMAIN\LINSERV01$
    -crypto DES-CBC-MD5 -pass password -ptype KRB5_NT_PRINCIPAL
    -out c:\krb5.keytab

    The Kerberos realm is the same as the AD DNS domain name in uppercase, and the -mapuser parameter specifies the account name of the computer account you just added to Active Directory. In the instance of needing multiple Linux servers to authenticate to Active Directory, you create a computer account for each of them and repeat the ktpass command for each computer account to create a unique keytab for each computer.

    Your login problems are all related to LDAP. Kerberos does nothing with regards to resolving UID/GID, and those errors in /var/log/messages along with the pam_ldap error indicates that your LDAP configuration is not working. Keep in mind that the CN of the account that you are using to bind to Active Directory may not be what you expect it to be–you may want to use something like ADSI Edit to find the true CN of the object. When LDAP is working properly, you should be able to use the command “id scott” (where “scott” is the name of a valid Unix-enabled account in Active Directory) and get back the UID and GID for that account (as specified in Active Directory). If that doesn’t work, then LDAP still isn’t working correctly.

    I have not tried to add SSL/TLS or use SASL yet, so I can’t really offer any guidance in that regard. Generally speaking, these types of connections occur on a trusted network segment and therefore SSL/TLS isn’t a real high priority.

  4. Scott’s avatar

    I tried the following with ktpass:

    ktpass -princ host/[email protected] -mapuser RUCKH\VMLNX01$ -crypto DES-CBC-MD5 -pass * -p type KRB5_NT_PRINCIPAL -out vmlnx01.keytab

    Targeting domain controller: gemneyedc.ruckh.net
    Successfully mapped host/vmlnx01.ruckh.net to VMLNX01$.
    Type the password for host/vmlnx01.ruckh.net:
    Type the password again to confirm:
    WARNING: Account VMLNX01$ is not a user account (uacflags=0×1021).
    WARNING: Resetting VMLNX01$’s password may cause authentication problems if VMLNX01$ is being used as a server.

    Reset VMLNX01$’s password [y/n]? y
    WARNING: pType and account type do not match. This might cause problems.
    Key created.
    Output keytab to vmlnx01.keytab:
    Keytab version: 0×502
    keysize 59 host/[email protected] ptype 1 (KRB5_NT_PRINCIPAL) vno 2 etype 0×3 (DES-CBC-MD5) keylength 8 (0x73465d2376587a5e)

    Are those errors correct?

    Then on the linux side:

    ktutil
    ktutil: rkt /home/sruckh/vmlnx01.keytab
    ktutil: list
    slot KVNO Principal
    —- —- ———————————————————————
    1 2 host/[email protected]
    ktutil: wkt /etc/krb5.keytab
    ktutil: q

    My comment about the krb5.keytab file was that your instructions do not say to append the contents to the /etc/krb5.keytab file but to copy the file created by keypass to the /etc/krb5.keytab file. If you have several linux machines you would just be over writing the /etc/krb5.keytab file. Is that correct? I thought the the above method was correct for adding additional servers to the keytab file?

    The “cn” value in my Active Directory for the account I am testing is the full name, “First Middle-initial Last”. The actually account I am trying to log in with shows up in AD as msSFU30Name, sAmAccountName and uid.

    I am still trying to wrap my head around all this stuff. Especially the kerberos stuff. I have been able to do simple LDAP queries with the LDAP tools. I obviously do not have the login stuff working, although I know the query is happening, and the correct account is being found.

    Thanks.
    Scott

  5. slowe’s avatar

    Scott,

    As I understand it, appending the keytab would only matter if you had generated keytabs from other Kerberos realms and needed those preserved as well. If your Linux servers are only authenticating via Kerberos to the Active Directory domain, then preserving the contents of an existing keytab shouldn’t really matter.

    Each Linux machine will have its own computer account in Active Directory, and ktpass will generate a file for each of them. For each computer, take the keytab for that specific system and copy it over to Linux. The file doesn’t need to stay on the AD domain controller; Windows doesn’t care about it. (It’s questionable whether Linux even cares about it, but that’s another story entirely.)

    I wouldn’t focus so much on your Kerberos stuff–if you can do a successful kinit (and then klist shows the ticket), then Kerberos is fine. You need to get your LDAP integration fixed in order to make the logins work correctly. Until you can make the “id” command resolve a username to a UID and GID, LDAP isn’t working correctly and logins aren’t going to work as expected.

    Hope this helps!

  6. Scott’s avatar

    if I run:

    ldapsearch -x -W -D “cn=scout,cn=Users,dc=ruckh,dc=net ” -LLL “(sAMAccountName=lnxacct)”

    (where the user scout is the account created to browse the AD for my LDAP searches, and lnxacct is the account set up in AD for Unix authorization)

    I get a whole bunch of LDAP information returned from AD about the account lnxacct. All which appears to be the correct information.

    When I try ssh lnxacct@localhost, I get prompted for password, I type in correct password and receive the Access denied error.

    I can see that the user scout was successfully logged into AD from the Windows security logs, and it obviously retrieved some information from AD because the pam_LDAP error contains information (dn and cn for the account lnxacct) from AD for the account lnxacct which could only be received from AD.

    I assume that this means LDAP is at least partially working.

    This leads me to believe that the most likely problem is with my nss_map statements in my /etc/ldap.conf.

    Your guide is one of very few which I have seen for Win2k3 R2. I am curious where you found which nss_map directives are necessary. Did you use the one straight from the RFC-2307 section of the /etc/ldap.conf file? As they are significantly different then ones used when using Win2k/2k3 w/SFU 3.5, I am just wondering if I am missing anything.

    I see in your /etc/ldap.conf file you have:

    nss_map_attribute uniqueMember member

    I will not pretend to understand LDAP, and these nss_map statements, but I have no field, member, in my AD database. The closest field I see is memberOf.

    I do not understand the nss_map_objectclass directives. Is that somehow using the objectClass field in AD schema? If so I do have user in that field and that would make some sense.

    I assume I am very close, but yet not close enough.

    Do you have any suggestions?

  7. slowe’s avatar

    OK, it had been a while since I’d really gotten into this in-depth, so I had to take some time and review it on a production server. I have it working right now on a production server, so hopefully we can get you to the same place.

    The ldap.conf nss_map_* statements are based in part on RFC 2307, since R2 implements a schema that is mostly RFC 2307 compliant. Note that this schema as implemented by R2 is VERY different than the schema used by SFU 3.0/SFU 3.5, which is why there are so many differences in ldap.conf between those sections. The purpose of the nss_map_objectclass is exactly what you have surmised; it links Unix user types (posixAccount or shadowAccount) to the corresponding AD user type. The nss_map_attribute statements, likewise, map Unix attributes to AD attributes. My AD tree is also lacking a “member” attribute, but that mapping is taken directly from the RFC 2307 portion of the ldap.conf and seems to work just fine. I don’t know for certain that memberOf serves the same purpose as uniqueMember. If I have time, I’ll do some testing and find out.

    You’ll also note that my ldap.conf uses the user principal name ([email protected]) of the LDAP bind account; you may try that syntax. It seems like Windows Server 2003 is more friendly to that login than to the old-style “CN=XX”-style logins. I’ve also used the LDAP URI to point to an AD DC; make sure that’s correct as well.

    In going back and testing my configuration, I found the following things to be hang-ups:

    - Password for the LDAP bind account
    - Time synchronization between Linux and AD (causes Kerberos to fail)

    I had to reset passwords on my LDAP bind account before the “id” command would work, and it wasn’t until the “id” command worked (retrieving information found on the UNIX Attributes tab of Active Directory Users and Computers) that I was able to log in again.

    What error messages are you still receiving when you attempt to authenticate as an AD user? Have you already created home directories for the AD users, or are you using pam_mkhomedir.so in your PAM configuration?

  8. Scott’s avatar

    The bind account seems to be working fine. As I mentioned before when I attempt to log in from a Linux box using AD account configured for authentication I see the bind user successfully loggin in by way of looking at the Windows’ Security Logs.

    The error returned in /var/log/messages is:

    Aug 3 11:17:49 lnxhost sshd[9148]: pam_ldap: error trying to bind as user “CN=First M. Last,OU=LNXUSERS_USERS,OU=LNXUSERS,DC=my,DC=domain” (Invalid credentials)

    Obviously the bind account went out to AD and found the correct account. That information about the OUs could only be obtained from talking to AD. My assumption then is that the bind account is working, and pam_ldap is at least talking to AD.

    I can also issue:

    ldapsearch -x -D “cn=scout,cn=Users,dc=ruckh,dc=net” -w secretpasswd

    and all of the information about the user, “scout”, is returned.

    Again, this appears to be a good sign. It looks like my Linux box and AD are at least having a conversation and are commuicating properly.

    Now the question, is why is the authentication not working.

    The error states Invalid Credentials. I have tried many times with different passwords but the results stay the same. I have reset passwords for the User who is configured for authentication and for the bind account. Again, the results remain the same.

    The commands `getent passwd’ and ‘id username’ do not work, or better state,do not work for LDAP user(s).

    my /etc/ldap.conf looks like the following:

    host x.x.x.x
    base ou=myOu,dc=my,dc=domain
    uri ldap://host.my.domain/
    binddn [email protected]
    bindpw myPassword
    scope sub
    ssl no
    nss_base_passwd dc=my,dc=domain?sub
    nss_base_shadow dc=my,dc=domain?sub
    nss_base_group dc=my,dc=domain?sub?&(objectCategory=group)(gidnumber=*)
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos name
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member
    pam_password ad
    nss_map_attribute userPassword authPassword

    Slightly different then what you had, but I believe I had a version which was more or less identical to yours, and I had the same results.

    I am using nss_ldap-226-10 on CentOS 4.3 i386.

    My clock synchronization is not perfect (Virtual Machine problem), but AD server and Linux machine are within a minute of one another.

    I am using pam_mkhomedir.so, but I do not think I am making it that far. It looks like the password I type in via SSH does not match whatever information is received from AD.

    I am sure I am close, but I can not readily locate the error.

    Thanks for your time and help.

  9. Scott’s avatar

    Turns out, I could not see the trees in the forest.

    Although I had once made the correct modifications to /etc/nsswitch.conf, I apparently forgot to put the changes back after restoring Virtual Machine. Once I added ldap back into nsswitch.conf, id and getent passwd starting working.

    Thanks.
    Scott.

  10. slowe’s avatar

    Glad to hear it’s finally working! I guess I should have remembered to ask you about nsswitch.conf.

  11. Doug’s avatar

    I’ve been silently watching/reading for the past few days and FINALLY got RHEL4 to authenticate against a R2 ADS. This has been a big help. One question that I have is do you really need to perform the ktpass step(s)? I was unable to get things working yesterday and figured I pick thing up with the ktpass directions today. I added my linux client to the ADS computers section (it was not there for any of my prior access attemtps) and then performed the ktpass step. However, prior to copying the generated keytab to my linux client, I attempted to login on my linux client with a user that was just defined in ADS and to my surprise, the users was able to login (and the users associated home dir was created on the fly). So I suspect that one needs to have the linux client computers that wish to authN/authZ against ADS added as part of the “managed computers”. Is this a correct statement or was it the adding of the client computer to the domain and running ktpass that “magic” that made things work? Thanks again for your help.

  12. Ron Terren’s avatar

    scott,

    I installed the Server for NIS, but I didn’t do anything with it, and when I go to the “Unix Attributes”, everything is greyed out until I select sso (which is my domain and I guess NIS name). Is it merely a formality so you can access everything else below, or is NIS somehow actually involved in this?

    You say:

    “After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Linux server that will enable the authentication.”

    Should each of my accounts have the same “10000″ value or do I just make up new numbers arbitrarily for each of them?
    Should I leave the “Primary Group name/GID” blank in all of them (if my limited linux knowledge is correct this GID setting is often set to the same value as the UID)?

    Thanks,

    Ron

  13. Ron Terren’s avatar

    scott,

    Another question for you, please excuse my ignorance:

    In number 6 you say to edit the Pam “stuff”, I think I did this by running system-config-authentication, was I suppossed to do it somewhere else?

    I’m running Centos 4.3

    Also I may actually be really close to having done this whole thing right, I can run kinit and give it a user name, and when i give it a correct password it returns a prompt, if i give it garbage it gives a failed authentication messgage.

    BUT I can’t login using any of the accounts I have created, nor can I run ssh what files if any should i post for your review?

    Thanks,

    Ron

  14. slowe’s avatar

    Doug – Because CentOS is configured NOT to verify the TGT by default (this is in the krb5.conf file), you actually don’t really *need* the keytab on the Linux server. However, as far as I am aware, you still need to perform the ktpass stuff. If I get a chance, I’ll do some additional testing in the lab to verify that.

    Ron – Each user will need a unique UID value on the Unix attributes tab, and you should pick a GID. Most Linux distributions use a “user private group” scenario, where every user has a matching group where the group’s GID matches the user’s UID. This is not required, but you will need to specify a GID for each user. Keep in mind that configuring Kerberos is only half the battle. You have kinit working, which is good, but now you need to configure LDAP to resolve UID and GID. Verify your /etc/ldap.conf contents, your /etc/nsswitch.conf, and then test with the “id” command.

  15. slowe’s avatar

    FYI, I’ve posted an updated version of these instructions, with a bit more detail.

  16. Scott’s avatar

    I have the following configuration:

    /etc/openldap/ldap.conf

    BASE ou=LNXUSERS,dc=example,dc=com
    URI ldap://1.1.1.1/
    HOST adsvr.example.com
    TLS_REQCERT demand
    TLS_CACERT /etc/openldap/cacerts/exampleCA.pem

    /etc/ldap.conf

    host adsrv.example.com
    uri ldap://1.1.1.1
    scope sub
    timelimit 30

    binddn [email protected]
    bindpw secret

    tls_checkpeer no
    ssl start_tls

    nss_base_passwd ou=LNXUSERS,dc=example,dc=com?sub
    nss_base_shadow ou=LNXUSERS,dc=example,dc=com?sub
    nss_base_group ou=LNXUSERS,dc=example,dc=com?sub?&(objectCategory=group)(gidnumber=*)
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos name
    nss_map_attribute homeDirectory unixHomeDirectory

    pam_password ad

    This configuration works without sending bind user’s name and password over the wire in clear text, and works for logging in from the local console, but it does not work for ssh logins.

    It looks like the user authenticates, but then receives a connection closed message. The /var/log/messages only shows a pam_krb5 message stating, “authentication succeeds for ‘aduser’ ([email protected])”.

    Does anyone have any idea what is going on and how to get ssh logins working?

  17. slowe’s avatar

    Scott,

    You didn’t mention your PAM configuration, so I can only guess that a PAM configuration exists for SSHD (either in /etc/pam.conf or, more commonly, in /etc/pam.d/sshd). Does the “id” command properly resolve UID/GID to user name and group name? What about any entries in /var/log/secure (in addition to /var/log/messages)?

  18. Scott’s avatar

    The following actually resolved the issue, but I am not sure what negative impact might be a side effect from the setting.

    The default pam_unix line in /etc/pam.d/system-auth was changed to the following (everything on a single line).

    account [ignore=ignore success=done default=die] /lib/security/$ISA/pam_unix.so broken_shadow

    To answer your question, yes `id aduser’ and `getent passwd ad user’ worked correctly.

    What I have in place is fuctionally working, but I need to do much more testing, and understand what ill effects the system-auth change might have.

    I will post all the configs once I run this setup through some proper testing.

    Thanks.

  19. Scott’s avatar

    Another question I have is about only having a single host entry in the /etc/ldap.conf file. Is there way to use SRV records from DNS to lookup domain controllers instead. Otherwise can you specify more then a single host on the on the HOST directive as you would in a standard LDAP implementation?

    Thanks.
    Scott

  20. slowe’s avatar

    Scott,

    I’ll do some research and see what kind of info I can find on that PAM setting as well, and I would definitely be interested in seeing what you can turn up as well. I certainly have more to learn myself!

    As to your other question, I don’t believe there is any way to use SRV records to find the DCs for LDAP queries, but you can specify multiple servers in the configuration file.

    Glad to hear it’s working for you.

  21. Scott’s avatar

    Do you have this problem?

    If your LDAP service is unavailable possibly due to AD server being down or a more likely scenario the network being down, your Linux clients come to a complete crawl? Once the AD server is available everything goes back to normal.

    I have read other posters in various forums state this same problem. I have tried all the hacks in the /etc/pam.d/system-auth file that I have seen suggested, but I have not come across one that provide a working solution.

    If you do not have this problem, could you post the contents of your /etc/pam.d/system-auth file.

    Thanks.
    Scott

  22. slowe’s avatar

    Scott,

    That is a known problem. Using the name service caching daemon (nscd) may help somewhat, but it may also introduce problems of its own. This is not a misconfiguration of PAM–this is due to the fact that the Linux server has to call the LDAP server to resolve UID and GID to human-readable names. As far as I know, no amount of work in your PAM configuration will fix this.

    The only workaround would be to maintain user accounts and groups on the Linux servers, but continue to use Kerberos authentication to Active Directory. It’s more administrative overhead, but it does eliminate the problem you describe.

  23. Scott’s avatar

    Do you change user passwords with linux tools (passwd, kpasswd, ldappasswd), or are all your password resets done using windows tools? I can configure it so that root users can change passwords, but I can not get regular users to be able to use linux tools to change password.

    If a user has been enabled for “must change password at next login” can you still login to linux server without having to change the password? This is true with my configuration. The user gets a Warning message, but can still log in to the linux server indefinitely.

    Thanks.
    Scott

  24. slowe’s avatar

    All password resets are done using Windows tools, since Windows acts as the authoritative source of accounts in the network.

    As for the “Must change password at next login question”, I personally haven’t tested it. I’ll see if I can reproduce the problem next week in the lab.

  25. SK’s avatar

    Hey slowe,

    I never saw whether or no this error “WARNING: Account VMLNX01$ is not a user account (uacflags=0×1021).
    WARNING: Resetting VMLNX01$’s password may cause authentication problems if VMLNX01$ is being used as a server.” was standard issue. are there any foreseeable issues arising from this?

  26. slowe’s avatar

    SK,

    It is not a problem. However, if you anticipate wanting to authenticate other services (say, Apache) via Kerberos as well, you should probably use a user account, since you’ll need a unique account for each service that will be authenticating via Kerberos. Refer to my article regarding Kerberos-based SSO with Apache and mod_auth_kerb for more information and examples. I also use this approach in discussing the integration of Solaris with Active Directory for authentication as well.

    Hope this helps!

  27. Mike Suding’s avatar

    My end goal is I am trying to use win2003 R2 as an NFS server and have login to linux using AD credentials and use some NFS exports on my new win2003R2 server. My domain controller is win2003 sp1 (ie not R2).
    I extended the schema using disc 2 (of R2) while sitting at my win2003 domain controller (ran good without errors). You mention that you have to install “server for NIS” on one domain controller to see the magic “unix properties” tab in ADUC. But…do i have to upgrade my domain controller from win2003 to win2003 R2? I dont see any “server for NIS” in my “windows components install list” on my win2003 domain controller.
    Any suggestions are appreciated.

  28. slowe’s avatar

    Mike,

    The schema is extended, so it’s now possible to store the attributes in AD, but you have no access to the attributes. You either have to upgrade your DC to R2 (which will then offer you the option to install Server for NIS) or you can try copying the nisprop.dll file (which exists in compressed form on the R2 CD, try using expand.exe to uncompress it) and using regsvr32 to register the file like so:

    regsvr32 nisprop.dll

    I personally haven’t tested this approach but I have heard from others that this is the DLL that enables the display of the UNIX Attributes tab in ADUC. However, I do not know if this will work if the OS itself hasn’t been upgraded to R2.

    You could also try following the directions for pre-R2 systems using Microsoft’s free Services for Unix (SfU) product.

  29. Shannon VanWagner’s avatar

    I followed your configuration steps and they work.. the only problem is that after I add ldap into the nsswitch.conf file it causes the machine to freeze up during login or after attempting a su user. Also, the getent groups command only lists some of the groups and then hangs.. If CTRL+C isn’t pushed after the getent command hangs, the machine will freeze up – assumingly from running out of memory.

  30. Kiryl’s avatar

    Okay
    all the steps work, however seems that account to bind to LDAP has to be a memeber of admin group :( otherwise new accounts are not getting into the system properly.
    This is the odd part, ldapsearch returns exact same info either it’s a mamber of admin group or not… however id “user” start working only if the ldapsearch account has been added to an admin group.

    am i diong something wrong here? cause i would hate to leave ldap.conf with info that part of admin group.

    thanks

  31. slowe’s avatar

    Kiryl,

    There must be something different about your configuration, because the LDAP bind account does not require any administrative privileges whatsoever in Active Directory. The account is only required because Active Directory doesn’t, by default, allow unauthenticated searches. Of course, this assumes a default AD configuration–have you performed any delegations, or locked down permissions within AD?

  32. Kiryl’s avatar

    Slowe,
    originally i had 2000 domain, which was (i think properly) upgrqaded to 2003 and then 2000 domain con troller was dismissed. As i mentioned, ldapserach return *exact* results if i bind as a guest or as admin.
    but for some reason… if i configure linux box to bind as user that has guest priviliges – ldapserach give all info back, however id “user” or getent “password” does not pulling coorect info.
    once i change to bind as “admin” then id and getent works fine.

    Also, i don’t think i have performed any specific lockdowns on AD in general.

    thank you for your help.

    Kiryl

  33. slowe’s avatar

    Kiryl,

    Are there any error messages being logged in the system logs on the Linux client(s)? The only thing that I can think of is that there are some security changes that have been applied away from the standards/defaults, and those settings are causing your problems. Any additional information you can provide would be helpful–logs, config files, etc. Feel free to send those via e-mail at scott dot lowe at scottlowe dot org (it’s better than posting them in the comments).

  34. Kiryl’s avatar

    Alright…. after spending many hours of trying to narrow down the issue i have end up with the following…. Fedora Core 3 boxes can authenticate with no problems at all, and they all can do “id USERNMAE” and get a proper result. The problem i’m having is with FC6 boxes. (note that firewall and selinux are disabled). Here is a funky part a user that belong to only one group in AD can be perfectly identified on the FC6 boxes, as soon as i make a user in Active directory to belong to more than one group, then FC6 boxes starting to act funky.
    Again FC3 doing just fine…. and this is what happens on FC6:
    #: id kiryl – get a proper response
    #: id kiryl – get a proper response
    #: id kiryl – Hanging :)

    basically i do 3 requests one after another one and the third one hangs. This is very unusual and kinda funny to me. At first i was thinking that my AD was not set up properly but then i have noticed that FC3 boxes doing just fine and only FC6 boxes are funky. then i thought okay maybe setup on FC6 was wrong… yet this strange behaivour occurs…. may be there is something different in FC6 libraries or a bug?

  35. Kiryl’s avatar

    Actually ignore my last post… i have just read the latest revised doc’s and seem that
    nss_base_group dc=bcu,dc=org?sub?
    &(objectCategory=group)(gidnumber=*)

    has fixed my problem!

  36. slowe’s avatar

    Kiryl,

    Glad you found a fix!

  37. Duncan Baillie’s avatar

    Hi Scott,

    do you know where we can get krb5-workstation-1.2.7-61 (to go with krb5-libs-1.2.7-61 on esxserver 3.0.1) so that we can run kinit, klist etc?

    Regards

    Duncan

  38. asif’s avatar

    On the AD, when i installed the “Unix Attributes” tab, everything there is greyed out, and i can only select NIS Domain to “”. What can i do ?

  39. Tommy W’s avatar

    Hi Scott

    Fantastic instructions and i have all of my Linux machines running and authenticating perfectly using native LDAP

    Since doing so however i seem to have a strange issue in that i can no longer create local groups

    The issue first struck me when i tried to install an application that tried to install a local group as part of the install, and i have since been able to replicate the issue whenever i run a ‘groupadd’ command. ‘getent group’ also returns the same error

    The error in question is:
    groupadd: /build/buildd/openldap2-2.1.30/libraries/liblber/sockbuf.c:82: ber_sockbuf_ctrl: Assertion `( (sb)->sb_opts.lbo_valid == 0×3 )’ failed.
    Aborted

    Have you any idea what might be causing this?

    This happens on ALL of my Linux machines since configuring AD authentication and is not specific to just one or two machines

    I have even built a new machine from scratch completely vanilla and get the same problem on it as soon as AD and LDAP have been configured

    any help would be greatly apreciatted
    Kind Regards and thanks in advance
    Tom

  40. Tommy W’s avatar

    Sorry to post two in a row but here is another version of the same error

    groupadd: /build/buildd/openldap2-2.1.30/libraries/liblber/sockbuf.c:82: ber_sockbuf_ctrl: Assertion `( (sb)->sb_opts.lbo_valid == 0×3 )’ failed.
    addgroup: `/usr/sbin/groupadd -g 1001 test’ exited from signal 6. Exiting.

    any help would be graetly apreciatted

  41. Sergio’s avatar

    Hi Scot,

    I made every step of the guide and I have the following error when login for ssh over linux mahine

    Jun 1 16:51:45 sas3 sshd[25082]: pam_krb5[25082]: no v5 creds for user ‘sperez’, skipping session cleanup
    Jun 1 16:51:51 sas3 sshd[25550]: pam_krb5[25550]: authentication fails for ‘sperez’ ([email protected]): Authentication service cannot retrieve authentication info (Cannot resolve network address for KDC in requested realm)
    Jun 1 16:51:51 sas3 sshd[25550]: pam_krb5[25550]: account checks fail for ‘sperez’: can’t resolve KDC addresses
    Jun 1 16:51:51 sas3 sshd[25545]: Accepted keyboard-interactive/pam for sperez from 10.29.1.11 port 20062 ssh2
    Jun 1 16:51:51 sas3 sshd[25545]: nss_ldap: reconnected to LDAP server ldap://10.29.1.27 after 1 attempt
    Jun 1 16:51:51 sas3 sshd[25545]: pam_krb5[25545]: no v5 creds for user ‘sperez’, skipping session setup
    Jun 1 16:51:51 sas3 sshd[25545]: nss_ldap: reconnected to LDAP server ldap://10.29.1.27 after 1 attempt

    sas3:/var # klist -keK
    Keytab name: FILE:/etc/krb5.keytab
    KVNO Principal
    —- ————————————————————————–
    4 HOST/[email protected] (DES cbc mode with RSA-MD5) (0xbc9731b6642aabd6)

    I do not know that I am wrong .. can you help me, please??

    Thanks in advanced and sorry for my English

  42. slowe’s avatar

    Sergio,

    Based on the log file snippet above, it looks as if your Linux system is failing to properly resolve a KDC (domain controller) in the realm (Active Directory domain). Double-check your krb5.conf and make sure that you can properly resolve the hostname of one or more DCs for the specified Active Directory domain.

    Good luck!

  43. Sergio’s avatar

    Hi Slowe,

    I can do a kinit without problems and the kdc server are properly resolve … but ssh from localhost or remote hosts not work

    Thanks

    sas3:~ # klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: [email protected]

    Valid starting Expires Service principal
    06/02/10 08:29:37 06/02/10 18:29:40 krbtgt/[email protected]
    renew until 06/03/10 08:29:37

    Kerberos 4 ticket cache: /tmp/tkt0
    klist: You have no tickets cached

Comments are now closed.