Linux-AD Integration, Version 4

This procedure allows Linux-based systems to authenticate against Active Directory. We use Kerberos for authentication, LDAP for account information, and Samba to help automate the process along the way. When this process is complete, AD users can be enabled for use on Linux systems on the network and login to those Linux systems using the same username and password as throughout the rest of Active Directory.

These instructions are designed for use with Windows Server 2003 R2. If you are looking for information on using Linux with a previous version of Windows, please refer back to this article. The only significant changes in the process involve the mapping of the LDAP attributes; otherwise, the procedure is very similar between the two versions of Windows.

Preparing Active Directory (One-Time)

Enable Editing/Display of UNIX Attributes

Based on my research, it appears that the partially RFC 2307-compliant schema is installed with Windows Server 2003 R2; this means that the schema does not need to be extended to include UNIX-specific attributes such as uid, gid, login shell, etc. However, while the attributes are there in the schema, there is no way to edit those attributes, and these attributes must be populated correctly in order for this process to work.

The easiest way to enable the editing of these attributes is to install the “Server for NIS” component on at least one domain controller. This will cause a new tab, labeled “UNIX Attributes,” to appear in the properties dialog box for users and groups. You’ll use this tab to edit the UNIX-specific attributes that are required for logins to Linux-based systems. Please note that due to the way this tab is displayed, you’ll need Schema Admin privileges in order to install the “Server for NIS” component on your domain controller. (More information on this issue is available here.)

You could just as well use LDP, LDIF files, ADSI Edit, or any number of other methods to display and edit these attributes. To make this process as seamless as possible, however, you’ll want to integrate the management of these attributes into Active Directory Users and Computers using the method described above.

Create an LDAP Bind Account

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. This helps minimize any potential security risks as a result of this account.

Prepare 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 configure the Linux server(s) for authentication against Active Directory.

Prepare Each Linux Server

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

  1. Edit the /etc/hosts file and ensure that the server’s fully-qualified domain name is listed first after its IP address.
  2. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed. If they are not installed, install them.
  3. Be sure that time is being properly synchronized between Active Directory and the Linux server in question. Kerberos requires time synchronization. Configure the NTP daemon if necessary.
  4. Edit the /etc/krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:
     default = FILE:/var/log/krb5libs.log
     kdc = FILE:/var/log/krb5kdc.log
     admin_server = FILE:/var/log/kadmind.log
     default_realm = EXAMPLE.COM
     dns_lookup_realm = true
     dns_lookup_kdc = true
     EXAMPLE.COM = {
      kdc =
      admin_server =
      default_domain =
    [domain_realm] = EXAMPLE.COM = EXAMPLE.COM
     profile = /var/kerberos/krb5kdc/kdc.conf
     pam = {
       debug = false
       ticket_lifetime = 36000
       renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
  5. 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. (Please note that the nss_base_group line should not be broken across two lines when you edit it; it has been wrapped here for readability.) (Note: These schema mappings assume that you are using the newer schema extensions provided by Windows Server 2003 R2. If you are using SFU 3.5 instead, you will need to use the schema mappings described here.)
    base dc=example,dc=com
    uri ldap://
    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=mydomain,dc=com?sub?
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos cn
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member
  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. Here’s a properly edited /etc/pam.d/system-auth file taken from CentOS 4.4 (some lines have been wrapped for readability; do not wrap them when editing the file):
    # This file is auto-generated.
    # User changes will be destroyed the next time authconfig is run.
    auth     required   /lib/security/$ISA/
    auth     sufficient /lib/security/$ISA/ likeauth nullok
    auth     sufficient /lib/security/$ISA/
    auth     required   /lib/security/$ISA/
    account  sufficient /lib/security/$ISA/
    account  sufficient /lib/security/$ISA/
    account  sufficient /lib/security/$ISA/
        uid < 100 quiet
    account  required   /lib/security/$ISA/
    password requisite  /lib/security/$ISA/ retry=3
    password sufficient /lib/security/$ISA/ nullok
        use_authtok md5 shadow
    password  required  /lib/security/$ISA/
    session  required   /lib/security/$ISA/
    session  required   /lib/security/$ISA/
  7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

At this point we are now ready to test our configuration and, if successful, to perform the final step: to join the Linux server to Active Directory for authentication.

Test the Configuration

To test the Kerberos authentication, use the kinit command, as in kinit <AD username>@<AD domain DNS name>; this should return no errors. A klist at that point should then show that you have retrieved a TGT (ticket granting ticket) from the AD domain controller. If this fails, go back and troubleshoot the Kerberos configuration. In particular, if you are seeing references to failed TGT validation, check to make sure that both your Linux servers and AD domain controllers have reverse lookup (PTR) records in DNS and that the Linux server’s /etc/hosts file listed the FQDN of the server first instead of just the nodename.

<aside>Some readers and some other articles have suggested the use of the AD domain DNS name in the /etc/krb5.conf file instead of an AD domain controller specifically; I recommend against this. First, I believe it may contribute to TGT validation errors; second, it is possible to list multiple KDCs (AD DCs) in the configuration. Since the only major reason to use the AD domain DNS name instead of the DNS name of one or more DCs would be fault tolerance, then it doesn’t really gain anything.</aside>

To test the LDAP lookups, use the getent command, as in getent passwd <AD username>; this should return a listing of the account information from Active Directory. If this does not work, users will not be able to login, even if Kerberos is working fine. If you run into errors or failures here, go back and double-check the LDAP configuration. One common source of errors is the name of the LDAP bind account, so be sure that is correct.

Join the Linux Server to Active Directory

This is the final step. Don’t try this step until you’ve successfully tested the configuration. After this step is completed, you are finished and AD users will be able to login to Linux-based systems (assuming the AD users have been properly configured for Linux logins).

To join the Linux server to Active Directory, follow these steps:

  1. Verify the Samba configuration. Be sure the following settings are specified in /etc/samba/smb.conf:
    workgroup = <NetBIOS name of AD domain>
    security = ads
    realm = <DNS name of AD domain>
    use kerberos keytab = true
    password server = <Space-delimited list of AD DCs>
  2. Use kdestroy to destroy any existing Kerberos credentials you may have; then run kinit <Domain administrative account>@AD.DOMAIN.NAME to get a Kerberos ticket for an account that is a domain administrator account.
  3. Run net ads join to join the Linux server to Active Directory. This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object. In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory.

Only one small detail remains: how to deal with home directories for users logging into Linux systems.

Deal with Home Directories

Unlike Windows systems, home directories are required on Linux-based systems. As a result, we must provide home directories for each AD user that will log in to a Linux-based system. We basically have two options here:

  • Use the PAM module to automatically create local home directories “on the fly” as users log in. To do this, you would add an entry for in the session portion of the PAM configuration file.
  • Use the automounter to automatically mount home directories from a network server. This process is fairly complicated (too involved to include the information here), so I’ll refer you to this article on using NFS and automounts for home directories. This has the added benefit of providing a foundation for unified home directories across both Windows and Linux systems.

(There is a third option as well: manually create home directories before users can log in.)

Once you’ve settled on and implemented a system for dealing with home directories, you are finished! UNIX-enabled users in Active Directory can now login to Linux-based systems with their Active Directory username and password.

What’s not addressed in this article? Password management. In this configuration, users will most likely not be able to change their password from the Linux servers and have that change properly reflected in Active Directory. I’ll try to work on that for version 5 of the instructions.

I hope you find this information helpful. As always, feel free to post corrections, additions, or suggestions in the comments below.

Tags: , , , , , , , ,


  1. Paul’s avatar

    Net ads join is working OK on my Ubuntu, is it possible to do it on Solaris 10 ? How dou you think ?

  2. slowe’s avatar


    The version of Samba that’s included with Solaris 10 (even the 11/06 or “Update 3″ release) do not include support for Active Directory compiled in, so “net ads join” doesn’t work on Solaris by default. I have been trying to compile a new version with AD support, but I keep running into various roadblocks and missing dependencies. Prepackaged Solaris binaries (from Sunfreeware or Blastwave) may work, but I haven’t yet tried those.

    As soon as I can compile or install an AD-aware version of Samba on Solaris 10 and test it, I intend to revise the Solaris-AD integration instructions on this site accordingly.


  3. steve’s avatar


    I was able to use your procedures to setup kerberos authentication to AD and
    user/group authorization to AD Windows2003 RC2.

    After I logon to the Linux server with using openssh, I do not have a kerberos ticket.
    :/> klist
    klist: No ticket file: /tmp/krb5cc_145538

    Any idea on how to get a ticket automatically? I can issue a kinit command to get a ticket
    but I thought the reason you were getting the server keytab was to allow the OS to get
    the ticket for us.

  4. slowe’s avatar


    You’ll only have a Kerberos ticket on the remote server if you use “native” Kerberos authentication as described here:

    Otherwise, you’re not actually talking Kerberos between the SSH client and the SSH server…it’s just the SSH server that’s using Kerberos on the back-end to authenticate the user.

    Of course, you could use some sort of script that executes when a user logs in…there’s always more than one way to accomplish your goal.


  5. ron terren’s avatar


    Taking all of this into account, does it matter if I want to raise the domain/forest functional level to the highest setting, or does it have to remain in mixed mode?



  6. slowe’s avatar


    As far as I am aware, you are free to raise the domain/forest functional levels to their highest available settings. Linux integration does not require mixed mode.


  7. Leonard’s avatar

    I have the single sign on working but would like to prevent user from AD to logon unless they are a member of a certain group. Any ideas on how to do this?



  8. slowe’s avatar


    Check out this article:

    It should provide the information you are seeking.


  9. Nico’s avatar

    Hi Scott,

    thanks for a *very* useful howto on linux-ad integration! I had been trying to get this to work for some time now.

    One remark: although I was working with a freshly installed Win 2003 R2 server (with SFU 3.5 installed) I had to use the old schema mappings in /etc/ldap.conf. It took me a while to figure this out. You may want to add this as a remark in your text.

    Thanks again!


  10. slowe’s avatar


    You are absolutely correct–if you are using SFU 3.5 on any supported version of Windows, you must use the “old” schema mappings in /etc/ldap.conf. I made the incorrect assumption that if you were using 2003 R2 you would not be using SFU 3.5–my mistake. I’ve updated the article accordingly. Thanks!


  11. John’s avatar

    I’m curious about the ‘Join the server to AD’ portion of this. It seems that once you have setup nss_ldap & krb5/pam_krb5, you will have functional authentication and authorization from AD on the system already (even with no samba). What additional benefits are gained from the join portions of the procedure?

  12. slowe’s avatar

    The joining of the server to AD creates a security principal in AD and generates all the keytab entries for the TGT validation that is part of Kerberos authentication. You can typically do Kerberos authentication without TGT validation by not including this step, but then you lose the assurance that the TGT is actually coming from the server that it’s claiming to be. Essentially, you lose mutual authentication.

  13. John’s avatar

    Ok, so I’m correct in what I was assuming is this is an alternate method of populating the keytab rather than the method used in the Solaris document (and Microsoft’s) where it’s exported via ktpass and manually migrated across. I just wanted to make sure this wasn’t doing some voodoo magic that I couldn’t see, since I don’t have samba-common in the base system.

    Have you done any work in the DNS based distribution of ADS communication from clients a-la what Windows clients natively do? That’s my next step. I think it may simply not be feasible though, and they will end up statically mapped to a pair of DCs.

  14. slowe’s avatar


    Yes, you are correct–using Samba in this case avoids the need to use ktpass.exe on the Windows side, then transferring the keytab to the Linux box, etc.

    As for the use of SRV records to lookup DCs in Active Directory, you can do that using the “dns_lookup_kdc = true” option in /etc/krb5.conf. However, I have seen some instances where TGT validation fails in that instance. Most implementations end up statically mapped to a couple of DCs.

  15. John’s avatar

    This would solve it for the krb5 portion, but I don’t think it would work for LDAP (in any method that I know) — which would leave you with authentication but no authorization. Is this incorrect?

  16. slowe’s avatar

    You are correct. As far as I am aware, the nss_ldap libraries do not have the ability to use SRV records to locate LDAP servers, so you’ll have to just use statically coded entries. You can, of course, list multiple LDAP servers in the configuration file.

  17. Ryan’s avatar


    Any new update on password management ? Thanks.

  18. slowe’s avatar

    Sorry, Ryan, no new updates on password management. I messed around with changing passwords from the Linux side but haven’t had time to explore it fully.


  19. JS’s avatar

    I have SSO working but I have a question. I can not add a local user since users authenticate to AD. Is it possible to add local users?

  20. Sean’s avatar

    Scott, thanks for this awesome website, everything worked out as you outlined it here. I am now trying to figure out how to get Password Synchronization working.

  21. Sean’s avatar

    JS, would you be so kind as to share what information you used to get SSO working? Thanks, Sean

  22. slowe’s avatar


    As long as you left the lines in the system-auth configuration, you should still be able to create and authenticate using local users.


    There are some additional configurations that are required in order to be able to change your password from the Linux side, especially during logon. I have not had the time to research this fully, so I can’t give you any definitive guidance. I hope to be able toa ddress this soon in another blog posting.


    Glad you are finding the site helpful. As soon as I have the chance to research some information on password synchronization, I’ll be sure to post it here.

    Thanks, everyone!

  23. CS’s avatar

    After following your steps to the letter I have this mostly working, however, I frequently get errors like this:

    [root@ad-linux ~]# ls -la /home
    ls: ../../../libraries/liblber/sockbuf.c:90: ber_sockbuf_ctrl: Assertion `sb != ((void *)0)’ failed.
    [root@ad-linux ~]# ls -la /home
    total 20
    drwxr-xr-x 3 root root 4096 Mar 14 18:15 .
    drwxr-xr-x 23 root root 4096 Mar 14 17:35 ..
    drwxr-xr-x 2 csmith 10000 4096 Mar 14 18:15 csmith
    [root@ad-linux ~]#

    Any ideas ?


  24. slowe’s avatar


    Looks like a bug of some sort in one of the libraries you have installed. I would guess it is the nss_ldap library or a related library, since the error manifests itself when resolving user names and group names to UIDs and GIDs, respectively. I’d suggest re-installing the nss_ldap library and any related packages and seeing if that resolves the issue.

  25. CS’s avatar

    Sorry, I should have provided some more details…

    This is a bone-stock CentOS 4.4 installation, done from scratch specifically to proof-of-concept this authentication. I’ve actually since reinstalled the machine again and it’s still returning the same errors. Additionally, anything that involves sucking down user information (eg: getent passwd, ls’ing a directory with files/directories owned by AD users, etc) is extremely slow.

    The DC is on the same network segment as the Linux machine and isn’t under any sort of load, so I don’t think that’s the problem.

    Since I’m using CentOS and you used CentOS, I’m just trying to figure out why we don’t have the same problems :).

    I am contemplating using SFU’s NIS server instead to grab the user information. A quick test indicates that it would work and doesn’t seem to have the “crashing” issue, but it’s still very slow. Thoughts ?


    (PS: I had these exact same issues the last time I tried to get this up and running, ~12 months ago – I just assumed at the time it was some bugs in the libraries that would be ironed out over time. Guess not…)

  26. slowe’s avatar


    Hmmm…that’s very odd. I’ve done this many times, from scratch, and haven’t run into this problem. Have you indexed any of the attributes used by authentication, such as UID? That can help with some of the performance concerns you mentioned. I’m not sure about the error messages and the crashing; that just doesn’t make sense.

    I’m not really sure what to suggest from here…have you tried any of the Linux newsgroups?

  27. CS’s avatar

    Fixed it ! The culprit was “LDAP referrals”. Having just spent several hours figuring it out, this actually refreshed my memory that it was the same problem – and its cause – that stopped me implementing this the last time (which, in my defense, was 18 – 24 months ago, now that I go back and search my emails, not 12 months).

    We have a slightly complicated domain structure in that we have multiple child domains (for each branch office). With referrals turned on, nss_ldap recurses down from to,, etc before returning results. There must be something that happens in this process that sometimes triggers the errors I was seeing (because they appear at random) and also causing the slowdowns.

    If you put:

    referrals no

    into /etc/ldap.conf, the problems all go away (or, at least, they haven’t happened since – with these sort of random errors you never can be 100% sure ;) ). Response time is also substantially faster.

    I can get away with this _now_ because (for unrelated reasons) we are flattening our domain structure and nixing the child domains. Previously this was not an option so any authentication system had to be able to include users in the child domains.

    I also seem to vaguely recall that you can get around much of the slowness related to multi-domain configurations by a) pointing at a DC that is a Global Catalogue and b) pointing at the GC port instead of the regular LDAP port. This didn’t help the random crashes with things like ‘getent group’ though, IIRC.

    Well, now all I need to do is get the automounter going with NFS’d home directories, and we’ll be golden. I might have to bend your ear about that shortly as well ;).


  28. slowe’s avatar


    Thanks for the update! I’ll have to see if I can get in some testing time with this kind of scenario, reproduce the problem, and then try the fix of using the GC and GC port instead of standard LDAP.

    Take care,

  29. Shannon VanWagner’s avatar

    Any ideas on how to set this up for Suse Linux Enterprise Desktop 10 -specifically the pam modules configuration section since they are a bit different from CentOS?

    Thanks for the great information!

    Shannon VanWagner

  30. slowe’s avatar


    I’m afraid I can’t offer much help in that regard, as I’ve never worked with that distribution. If you want to send over your existing system-auth (or equivalent), I’ll look and it and I might be able to make some recommendations.

    Hope this helps,

  31. Shannon VanWagner’s avatar

    Hi Scott,

    Thanks for your reply. Here’s a more detailed description of my problem with configuration file information included:

    RE: Sled 10 System Hangs When Using Ldap / kerberos To Authenticate To Server 2003 R2

    I’ve configured LDAP/Kerberos authentication on SLED 10 and am trying to authenticate to Active Directory on Windows Server 2003 R2. Note: the UNIX attributes for each user are showing up in active directory.

    The authentication seems to work as it lets me login as a Windows user. I can also run id and get the correct uid for that user. However, after logging in there are serious system performance issues (to the point where the system freezes up after about 10 min).

    wbinfo -u and wbinfo -g show all domain users and domain groups as expected

    However, when I run the getent passwd or getent group commands I get a listing that shows some of the Active Directory users and then the listing gets stuck and never returns to the command line. After that, if I don’t use CTRL+C to exit the getent listing, the computer freezes up as if it’s stuck in a loop or something.

    I’ve already successfully had authentication working properly with the same client/server using winbind instead of ldap – that solution doesn’t give me the uid/gid mapping I need however. This makes me think there’s something I’m missing with the ldap configuration or something.

    Here are my configs:

    ——————— /etc/nsswitch.conf——————————
    # An example Name Service Switch config file. This file should be
    # sorted with the most-used services at the beginning.
    # The entry ‘[NOTFOUND=return]‘ means that the search for an
    # entry should stop if the search in the previous entry turned
    # up nothing. Note that if the search failed due to some other reason
    # (like no NIS server responding) then the search continues with the
    # next entry.
    # Legal entries are:
    # compat Use compatibility setup
    # nisplus Use NIS+ (NIS version 3)
    # nis Use NIS (NIS version 2), also called YP
    # dns Use DNS (Domain Name Service)
    # files Use the local files
    # [NOTFOUND=return] Stop searching if not found so far
    # For more information, please read the nsswitch.conf.5 manual page.

    # passwd: files nis
    # shadow: files nis
    # group: files nis

    passwd: compat ldap
    shadow: compat ldap
    group: compat ldap

    hosts: files dns
    networks: files dns

    services: files
    protocols: files
    rpc: files
    ethers: files
    netmasks: files
    netgroup: files nis
    publickey: files

    bootparams: files
    automount: files nis
    aliases: files


    base dc=mydomain,dc=com
    uri ldap://
    binddn cn=linuxldap,cn=Users,dc=mydomain,dc=com
    bindpw mypassword
    scope sub
    bind_timelimit 15
    timelimit 15
    ssl no
    nss_base_passwd dc=mydomain,dc=com?sub
    nss_base_shadow dc=mydomain,dc=com?sub
    nss_base_group dc=mydomain,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 cn
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member
    nss_initgroups_ignoreusers root,ldap


    sldtenghst:~ # cat /etc/samba/smb.conf
    # smb.conf is the main Samba configuration file. You find a full commented
    # version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
    # samba-doc package is installed.
    # Date: 2007-02-07
    workgroup = INTERNAL
    realm = MYDOMAIN.COM
    security = ads
    use kerberos keytab = true
    password server =
    netbios name = suse10box
    winbind use default domain = yes
    winbind separator = +
    idmap uid = 1000-29999
    idmap gid = 1000-29999
    winbind enum users = yes
    winbind enum groups = yes
    #deadtime = 15
    #winbind cache time = 10
    winbind nested groups = yes
    template homedir = /home/%U
    template shell = /bin/bash
    client use spnego = yes
    socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
    dns proxy = no
    domain master = no
    preferred master = no
    max log size = 100
    log file = /var/log/samba/%m.log
    printing = cups
    printcap name = cups
    printcap cache time = 750
    cups options = raw
    map to guest = Bad User
    include = /etc/samba/dhcp.conf
    logon path = \%L\profiles\.msprofile
    logon home = \%L\%U\.9xprofile
    logon drive = P:
    usershare allow guests = Yes


    auth required
    auth sufficient
    auth required


    account sufficient
    account required


    password required nullok
    password required nullok use_first_pass use_authtok


    session required
    session required
    session required umask=0077 skel=/etc/skel


    Thanks again!

  32. Shannon VanWagner’s avatar


    The previous posting from CS fixes my problem with LDAP hanging up!!
    (per the posting by CS above) I put this in the /etc/ldap.conf file:
    referrals no
    The system hangup on getent passwd has disappeared – Thanks VERY MUCH to CS and Scott for having this information posted online!!

    Now my NEW problem is that I don’t seem to have my pam files configured correctly..
    I can su and that works great (with correct uid) but I can’t login at the front screen of the computer.

    The errors logged in /var/log/messages show:
    gdm[pid] pam_krb5[pid]: error resolving user name ‘windows-user’ to uid/gid pair
    gdm[pid] pam_krb5[pid]: error getting information about ‘windows-user’
    gdm[pid] pam_krb5[pid]: Couldn’t authenticate user

    I’m thinking I need to add pam_ldap to my pam config files but I’m not exactly sure

    Thanks very much for your assistance!!

  33. Shannon VanWagner’s avatar

    *****************UPDATE 2***************************
    Fixed the above problem with a posting by “weeden” at
    ——————————–original posting—————————————————
    I found this which solved most of the problems.

    It doesn’t mention the following changes to the smb.conf file

    idmap backend = ldap:ldap://
    ldap idmap suffix = dc=domain,dc=com
    ldap admin dn = cn=Administrator,cn=Users,dc=domain,dc=com
    ldap suffix = dc=domain,dc=com

    Save the conf file and run “smbpasswd -w ADMIN_DN_PASSWORD”

    Then run: (to get the Windows User’s Passwords and Groups)
    getent passwd
    getent group

    Add to /etc/pam.d/system-auth
    session optional /lib/security/$ISA/

    And you’re ready to go! You will now beable to login via X with your Windows user name and password
    ——————————–original posting end———————————————–

    Now I have a NEW problem:

    When I su , I don’t get prompted to enter a password. Do you know how to configure my pam configs so that when su’ing to any windows user (as root) I will get the password prompt for that user? (example: su administrator — no password prompt).

    Thanks very much!

  34. Shannon VanWagner’s avatar

    Note: the previous comment should say that I found the information in a comment left by user “weeden” at

  35. slowe’s avatar


    First off, I’m glad that you were able to find information here to fix the LDAP “hangup” that was plaguing your system. I’m excited to see a bit of an ecosystem forming here where users are sharing valuable information on AD integration tasks.

    With regards to your su problem, it sounds to me like a PAM configuration issue. Some distributions have a PAM configuration that will implicitly trust members of certain groups or members with UIDs below a certain level. We’d need to review your PAM configuration for su in order to know if this is the case. You are welcome to shoot me an e-mail (scott dot lowe at scottlowe dot org) if you’d rather not post it here in the comments.

  36. Shannon VanWagner’s avatar

    SUSE Linux Enterprise Desktop ( SLED ) 10 Single Sign-On LDAP / Kerberos Authentication to Active Directory on Windows Server 2003 R2

    Important Note: It’s been a bit of an emotional roller coaster for two weeks (with much blood, sweat, and tears involved) getting this to work… What’s depressing is that I haven’t found any resource that gives me absolute specific instructions on how to set this up for SLED 10.

    Hehe, It’s time to “jerk the chain” a little for the Novell SLED 10 phone support…. I’d like to mention that I’ve called this whole problem in as a support ticket to Novell – I told them that I was fully able to authenticate with winbind from SLED 10 to Windows AD. The problem was that the winbind method didn’t appear to offer any way to sync user/group UID/GID across platforms, Novell confirmed this is true. The support guy actually said I should install eDirectory (Novell Product – go figure) in order to use LDAP authentication from SLED 10 to AD… Apparently Novell’s support team is not fully aware of the fact that Windows Server 2003 R2 is ready (out of the box) to support authentication and user/group UID/GID mapping from Active Directory LDAP to SLED 10. Hopefully Novell will catch on to this useful fact quick so that more sysadmins such as myself can use SLED 10 to its greatest ability for the great OS it is. SLED 10 truly is a very nice product!! Good Job Suse Devs, and Thanks!

    So here’s how to configure SLED 10 to connect with Server 2003 R2 Active Directory via LDAP…

    (Editor’s Note: The remainder of the information in Shannon’s comment has been moved into a post of its own:

    The information was detailed enough and extensive enough that I felt it warranted a full blog posting of its own. -SL)

  37. alaxa’s avatar

    this guide grows up very interestingly. great!
    I still have no solved my problem where in SuSE10.1 sometime any process that involves the LDAP query hangs eating all the CPU. I found that disabling the group mapping in ldap.conf everything goes fine.
    Anyhow, my new question is if it is possible to renew the kerberos ticket got at the login.
    I mean, the ticket expires after sometime, I could renew it by hand but I have to check periodically if it’s going to expire or not. On the other side users are not so skilled to do a kinit any X hours so they cannot access to many kerberized applications.

    thanks for any input

  38. Taras S.’s avatar

    I spent much time to get ktpasswd work (Heimdal was saying “Soft error”, MIT – “Password change rejected”). As I expected, solution was simpe: password change via ktpasswd didn’t work only because of one thing in domain group policy: by default in AD environment password can’t be changed by user more often then once per day ;-)

    My install:
    Fresh Windows Server 2003 R2 Std, FreeBSD 6.2 with Heimdal(base) or MIT(ports).

  39. slowe’s avatar


    Can you share more information on what you did to make ktpasswd work with AD? As I’m sure you’ve noticed, there’s a lot of interest here in that configuration.

  40. McDouglas’s avatar


    I’m trying to implement this integration in a test environment. I’m not an expert, and i run into a problem I’m not sure about.

    I followed you instructions, and installed the libraries on a newly installed Debian. However, after that i ended up with an /etc/ldap/ldap.conf file and with an /etc/libnss-ldap.conf one.
    You say i should put the ldap configs in /etc/ldap.conf … now, what should i do?
    1, create the file /etc/ldap.conf?
    2, edit /etc/ldap/ldap.conf?
    3, edit /etc/libnss-ldap.conf?

    I’m not sure which one is the correct solution, and i don’t want to mess up something in the long run.


  41. slowe’s avatar


    I’m not that familiar with Debian, but I’d have to say that the file you want to modify is the /etc/libnss-ldap.conf file. This should be the file that controls the behavior of the name switch service interface to LDAP, and that’s what you need.

  42. McDouglas’s avatar


    I hit another problem. The kerberos test is woking fine (kinit&klist) however i do not get any data with getent. I did try placing the ldap information in all 3 files (one at a time, and also everywhere)

    As far as i know PAM should not effect the results of getent, right? Only the nsswitch.conf, which is:

    passwd: ldap compat
    group: ldap compat
    shadow: ldap compat

    hosts: files dns
    networks: files

    protocols: db files
    services: db files
    ethers: db files
    rpc: db files

    netgroup: nis

    Any idea what could be the problem?

    Config files:


    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

    default_realm = TESTDOMAIN.LOCAL
    dns_lookup_realm = true
    dns_lookup_kdc = true

    kdc = mmserverr2.testdomain.local:88
    admin_server = mmserverr2.testdomain.local:749
    default_domain = testdomain.local

    .testdomain.local = TESTDOMAIN.LOCAL
    testdomain.local = TESTDOMAIN.LOCAL

    profile = /var/kerberos/krb5kdc/kdc.conf

    pam = {
    debug = false
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false



    base dc=testdomain,dc=local
    uri ldap://
    binddn [email protected]
    bindpw ***
    scope sub
    ssl no
    nss_base_passwd dc=testdomain,dc=local?sub
    nss_base_shadow dc=testdomain,dc=local?sub
    nss_base_group dc=testdomain,dc=local?sub?&(objectCategory=group)(gidnumber=*)
    nss_map_objectclass posixAccount user
    nss_map_objectclass shadowAccount user
    nss_map_objectclass posixGroup group
    nss_map_attribute gecos cn
    nss_map_attribute homeDirectory unixHomeDirectory
    nss_map_attribute uniqueMember member

  43. slowe’s avatar


    Everything seems to look OK; I’m not sure why it’s not working. Some quick questions:

    - I assume that you have the correct password and name for the LDAP bind account? When using user@domain, you must make sure this matches the account’s UPN in AD.

    - No DNS problems?

    - Does the “id” command work, i.e., “id aduser”?

    - No firewall rules that could be blocking LDAP traffic from the Linux client to the AD server(s)?

    Let me know about this stuff and let’s see if we can get you working.

  44. McDouglas’s avatar


    Yes, the password is correct, i can login with the password for the bind user account on the windows.

    As for dns, each machine has an A and a PTR record, in the dns server (which is the domain controller itself). Besides that, everything is left default as the win2k3 r2 made it after completing a new install and adding the AD and DNS roles.

    Can’t test “id” right now, will do tomorrow. But if i read it right, it resolves the username to uid, right? It should get its info from the ldap too :\ So i suspect it wont work.

    No firewall is present.

  45. McDouglas’s avatar

    Hi Scott,

    After reinstalling the debian to make sure I did not make any misstakes it still does not work. However i did play with ldapsearch to see if the connection does work at all or not, and here is the result:

    debian:/# ldapsearch -x -b “dc=testdomain,dc=local” “(objectclass=*)”
    # extended LDIF
    # LDAPv3
    # base with scope subtree
    # filter: (objectclass=*)
    # requesting: ALL

    # search result
    search: 2
    result: 1 Operations error
    text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope
    ration a successful bind must be completed on the connection., data 0, vece

    # numResponses: 1

    So, according to this, there is sime kind of bind problem…. but what? The bind user exists nad the password is correct (can log in on windows)…

    One question maybe: do i have to configure the unix attributes on windows for this bind user too? Like putting it into a nis domain?

  46. McDouglas’s avatar


    I was wrong, the ldapsearch does not take the bind parameters from the ldap.conf file, instead its specified int he cmd line. And after doing so, it did list the ldap info from the windows server.

    So, the ldap connection works, can use the bind user…. why does not work the getent?

  47. slowe’s avatar


    What is being reported in the system logs? Anything?

1 · 2 · 3 · 4 ·

Comments are now closed.