Monday, November 29, 2010

AD Authentication with RHEL 6

We’ve been using AD authentication with our RHEL and CENTOS 4 and 5 systems for some time, now, so I was anxious to see what kinds of changes might have come up with RHEL6. Not much, happily, but there was one change that took a little while to figure out. We’ll run through all the steps, from beginning to end, here.

Install the prerequisites

We’re using samba and samba-winbind for this, so make sure these are installed.
yum install samba samba-winbind
If you’re running RHEL5 and a Windows 2008 R2 domain, you’ll want to use samba3x, instead of the samba. See this article for more information on that front.

Edit the Configuration Files

you’ll want to have the following settings. I’ve grouped them here to make it all more readable. Changes from the default are in blue.


default_realm = EXAMPLE.COM dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = yes [realms] EXAMPLE.COM = { default_domain = } [domain_realm] = EXAMPLE.COM = EXAMPLE.COM
Here we’re defining the kerberos realm and domains. “” will be replaced with your AD domain name. Do note the capitalization; it matters.


workgroup = example realm = EXAMPLE.COM security = ads idmap uid = 10000-500000 idmap gid = 10000-500000 template shell = /bin/bash winbind use default domain = true winbind offline logon = false winbind nested groups = yes encrypt passwords = yes
Here we’ve told samba to use the kerberos realm EXAMPLE.COM (you’ll substitute your domain from the krb5.conf file). We’re using ads for security (Windows-style), and we’re allocating a bunch of UIDs and GIDs for mapping the domain users and groups to the Linux equivalents.


passwd: files winbind shadow: files group: files winbind
Here we’re telling the system to look not only in the /etc/passwd and /etc/group files for authentication, but also to use winbind.

Join the Domain

Now’s the fun part: we can join the system to the domain.
chkconfig smb on service smb restart net ads join –U username
where username is a domain user who has permissions to join a computer to the domain. You should get a response that the server has joined your realm.
Depending on your DNS configuration, you might get some errors like the following:
[root@linuxserver1]# net ads join -U username Enter username's password: Using short domain name – EXAMPLE Joined 'LINUXSERVER1' to realm '' [2010/11/29 16:11:20.643445, 0] libads/kerberos.c:333(ads_kinit_password) kerberos_kinit_password LINUXSERVER1$@EXAMPLE.COM failed: Client not found in Kerberos database [2010/11/29 16:11:20.644894, 0] utils/net_ads.c:1147(net_update_dns_internal) net_update_dns_internal: Failed to connect to our DC! DNS update failed!
So long as your server created a machine account in the domain, you can ignore the above errors. It’s trying to update your DNS server, and if you’re not using a Microsoft DNS server as a part of your domain, it will fail. That’s OK.
Once you’ve joined the domain, we need to start winbind
chkconfig winbind on service winbind start
Assuming winbind starts without any errors, you can test your membership and domain communication with the wbinfo command:
wbinfo –g
This command should list out all of the groups you’ve got configured in your domain.

Configure the home directories

We’ll first want to edit the /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf file; this defaults to creating home directories that are group- and world-readable. We don’t want that. This, BTW, is a change from what we did in RHEL 5 and below.
There are two lines in the /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf file that look like this:
<helper exec="/usr/libexec/oddjob/mkhomedir -u 0022"
Change them to read:
<helper exec="/usr/libexec/oddjob/mkhomedir -u 0077"
Then restart the oddjobd service
service oddjobd restart

Set the domain home permissions

*Note:  the behavior below is reported as fixed in advisory RHBA-2011:0339-2, but I'm leaving the information here for posterity's sake.  
There's a curiousity with the way oddjobd works, here: it seems to be assuming that the default umask is 0022 (644 permissions equivalent). When we change the umask 0077 (700), it not only creates the users' home directories with these permissions, but *also the domain home*. As it turns out, the domain home (/home/DOMAIN) is owned by root. This prevents anyone from being able to get to their home directory.
Unless we change this, users will receive the following error:
Could not chdir to home directory /home/DOMAIN/user: Permission denied -bash: /home/DOMAIN/user/.bash_profile: Permission denied
But if we pre-create the domain home, we should be in good shape:
mkdir /home/DOMAIN chmod 711 /home/DOMAIN
Where DOMAIN is the short name of your AD domain.
There's a bug for this behavior, BTW, at, if you're interested in such things.
This should set you up so that everyone can change directories to this, but no one can read or write to this directory. If you prefer users to be able to enumerate the contents of your DOMAIN directory, change the permissions to 755 instead of 711.

Restrict Logins

We’ll first edit the /etc/pam.d/password-auth file (you can have the OS do this with a GUI front-end for you, if you run authconfig-gtk). This tells pam to use, in addition to the local user store, winbind for authentication.

Domain authentication isn’t that useful unless you can use it to control who can and cannot log in to your server.
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required auth sufficient nullok try_first_pass auth requisite uid >= 500 quiet auth sufficient use_first_pass auth required account required broken_shadow account sufficient account sufficient uid < 500 quiet account [default=bad success=ok user_unknown=ignore] account required password requisite try_first_pass retry=3 type= password sufficient sha512 shadow nullok try_first_pass use_authtok password sufficient use_authtok password required session optional revoke session required session optional session [success=1 default=ignore] service in crond quiet use_uid session required
The mkhomedir line has PAM create a home directory (defaulting to /home/DOMAIN/username). That’s usually a good idea.
It’s possible to put login restrictions here in the system-auth file, but it’s usually considered best practices to put those in the individual files for the connection methods. We’ll do that now.


#%PAM-1.0 auth required auth include password-auth auth include system-auth account required account include system-auth account sufficient account required user ingroup DOMAIN\linuxadmins password include system-auth # close should be the first session rule session required close session required # open should only be followed by sessions to be executed in the user context session required open env_params session optional force revoke session include password-auth
Here we’re telling pam that only users who are in the group linuxadmins are allowed to connect to our server though ssh.


#%PAM-1.0 auth [success=done ignore=ignore default=bad] auth required user != root quiet auth required auth substack system-auth auth optional account required account include system-auth account sufficient user = DOMAIN\user34 account sufficient user ingroup DOMAIN\linuxadmins account required user ingroup DOMAIN\domainadmins password include system-auth session required close session required session optional session required open session optional force revoke session required session optional auto_start session include system-auth
We’re giving more people access to the GUI login, though. Notice that we’re allowing user34, linuxadmins, and domainadmins to log in through GDM.


  1. Great info! Playing with this now.

  2. Good write up. One question though. Did you have any problems with the user directory creation using oddjobd? I have everything working except that part. If I 'su - username' as root to a user before logging in with that account via ssh then the home directory is created with the su command and there is no problem, but if I don't do that 'su -' first then I get this...

    Could not chdir to home directory /home/DOMAIN/username: No such file or directory

  3. Aha. Yes, I've run in to that problem, as well. My experience is that this is a file perm problem. I've corrected this problem by changing perms (or ACLs, more recently) on the domain home directory.

    If, for instance, your domain name is BLAH, then you'll have a directory named /home/BLAH, and the domain users will have their individual homes under that directory.
    If you change the group of that domain dir to the default domain group (in our case, "Domain Users"), and give that group write privs on the domain directory (750, in our case), things should work.

    I seem to recall that, in my case, the home directories were created, but the user couldn't access it, due to the fact that domain users didn't have execute privs on the domain directory. That is: the user's home dir was created, and perms on it were fine, but the parent directory wasn't created such that the domain user could access anything within it.

    I don't have access to a system I can test this with right now, but when I do, I'll see if I can verify this.

    Let me know if this has some relationship to what you're seeing. If so, I'll update the post.

    Thanks for the feedback! -Lane

  4. As a follow-up: it might be that the domain directory requires domain users to have write privs (770). When I have a chance, I'll do some actual testing so I can post (more) intelligently.

    I'd love to hear if this helps your situation.

  5. Lane,

    Thanks for the suggestion. Granting permissions on that '/home/domain' directory did in fact eliminate the problem creating the user's home directory during their first login attempt. I am curious why this should be necessary for rhel6 when it wasn't in rhel5 though.


  6. Ah, very nice. Thanks for the follow-up! So I've done some digging, and this is what it's looking like:

    oodjobd runs as root, so the domain home /home/DOMAIN is created under that context.
    It appears that oddjobd-mkhomedir is assuming the default umask of 0022 (world read). When we change the umask to 0077, not only are the user directories created with that permission level (700), but the domain home is, as well.
    The solution appears to be to pre-create the domain home and set permissions appropriately (I suggest 711).

    I'm not sure if this is new behavior for oddjobd; we used the pam_mkhomedir module in RHEL5, so we weren't using oddjob in this process. That's been deprecated, so we're using oddjobd in RHEL6, which would account for the behavior change.

    Thanks again for the feedback! I really do appreciate it. I've updated the post with this additional information.

  7. I've filed a bug for this, BTW.

    Pre-creating the domain home works well, but maybe there's another (better) way to address the problem.

  8. I found that on RHEL6 I had to get package "samba-winbind" then start winbind service. wbinfo is not part of this new package.

  9. What's the advantage of using pam_oddjob_mkhomedir in place of pam_mkhomedir ?

  10. @ Al Said

    wbinfo is part of samba-winbind.

    [root@rhel6test ~]# rpm -qf /usr/bin/wbinfo

  11. Al, thanks for the follow-up re: wbinfo; that's great clarification.

    @Anonymous, re: using pam_oddjob_mkhomedir vs pam_mkhomedir, the truth is that I found the oddjob setup to be easier than the pam_mkhomedir. I don't, honestly, remember the difficulties I ran into with pam_mkhomedir, and I know that others have gotten it to work with RHEL 6.

  12. Hey Guys

    I get the following error after configuring it all. We have been using smb/winbind/krb for quite some time with rhel5 and only ran into this problem since rhel6. I also have the same problem when replacing smb packackes on rhel5 with samba3x ones.

    Anybody ever seen this before?

    # net ads -U adadmin join
    Enter adadmin's password:
    Failed to join domain: failed to lookup DC info for domain 'MYDOMAIN.LOCAL' over rpc: Invalid workstation

    We configure everything with authconfig, and then some vars manually in smb.conf. But it's all the same as in rhel5, and it works great there!?

  13. Dear Lane

    I was also experiencing problems with the ( umask=0077 on my RHEL6/CentOS6.
    Unfortunately the permission was not correctly set for the user's home.
    Changing it to the RHEL5/CentOS5 style solved the problem for me.
    But maybe it's not recommended to change this setting in the (/etc/pam.d/password-auth-ac) file.

    session required skel=/etc/skel umask=0077

    session required skel=/etc/skel umask=0077


  14. Hey there,

    Thanks for posting this. I just attempted to configure this on my SL6 system and it's not working. I had a very similar setup on CentOS5 and it was working correctly.

    Is there any obvious troubleshooting steps can I should be looking at? /var/log/secure just says "Failed password for ..."


  15. @anonymous with "NT_STATUS_INVALID_WORKSTATION" errors, there were, as I recall, some serious changes made in RHEL6 samba packages. If you run through all of the config files manually, do they match with the settings above?

    re: the oddjob_mkhomedir error, do the home directories get created correctly when you pre-create the /home/DOMAIN dir? I've had very good luck with that.

    Can you post some more info? Are you getting an error when you try to join the domain? Or is it when you try to access domain resources?

    I'd start with issuing a kinit command, something like this:
    kinit user@DOMAIN.COM
    it'll ask for a password, and then it'll dump you back to the prompt. Then use klist to list your kerberos tickets. If this piece was successful, then you can focus on winbind, as kerberos is functional.

    See for more on the kinit stuff. Let us know what you find!

  16. @Lane - thanks for getting back to me.

    All I'm trying to do is login via ssh. kinit and klist look to be working fine - no errors at kinit and klist shows my ticket - looks good.

    /var/log/samba/log.smbd is not showing anything when the login fails.

    I'm not sure how to proceed with troubleshooting, your suggestions are most welcome.



  17. Aha, you should see login errors in /var/log/secure and perhaps /var/log/sshd (I forget if you'll have that dir or not). SSH ought to log to /var/log/messages, as well.

    My hunch is that one of your PAM modules isn't working correctly; I'd look especially closely at that. I've spent many hours troubleshooting a login, only to find a PAM cfg file error was killing me.

    Definitely check out your secure log file; I'll bet you'll get some more information there.

    Hope that helps!

  18. /var/log/secure is saying "Failed password for ".

    I've double checked all the config files and everything looks good. wbinfo works fine, id looks good - shows me all the right group memberships etc.

    I'm at a loss...

  19. Definitely agreeing with you that the problem lies with some PAM config file, I ran the following command to get authconfig to set all that up for me. This resolved my problem - everything is working well now.

    authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup=ARRAY --smbrealm=ARRAYBP.COM --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/ARRAY/%U --winbindtemplateshell=/bin/bash --enablekrb5 --krb5realm=ARRAYBP.COM --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall

  20. Eddy, that's great; I'm glad it's working! Thanks for sharing the authconfig switches you used. Any differences in any of the PAM cfg files jump out at you, vs what wasn't working before?

  21. (Dave)
    Lane.. thanks for this excellent post, with it, I have been able to make excellent progress.

    I've followed your isntructions nearly verbatim on a new built system, up to the point the point you you begin editing the PAM files, and this is where I was forced to digress.

    On my system, pam.d/system-auth is a link to system-auth-ac.d. The text you listed for the file matched mine exactly, so I made the 4 insertions that you show.

    Upon editing that file, I had sucees! -- I could login with domain credentials from any local tty session. Based on your comments, I expected that also by default, I would be able to logon anny domain account via sshd or to the gnome desktop (i.e., I thought the mods to pam.d/sshd and pam.d/gdm that followed were requires to futher lock down those channels). But when I tried loging in vai Domain credentials with ssh our gdm I failed.

    SO I moved ahead to try to edit the files as you indicated, first on SSH. However, that is where I started running into problems.

    My pam.d/sshd file dioffers slightly from what yours listed. It reads like this:

    [root@pcmjnkh96 pam.d]# cat sshd
    auth required
    auth include password-auth
    account required
    account include password-auth
    password include password-auth
    # close should be the first session rule
    session required close
    session required
    # open should only be followed by sessions to be executed in the user context
    session required open env_params
    session optional force revoke
    session include password-auth


  22. ...continuatuion ... not sure if other portion will post....

    In the list above, you can see that "auth include system-auth" and "account include system-auth" are not present in my default file before editing. "password include system-auth" also is not present.

    I placed these lines in the file, as well as adding the "pam_succeed" lines. However, so dice in getting authintication via SSH. I tried a few other variations, but still no luck.

    Any thoughts? Did I understand you correct, that the the mods system-auth-ac.d should have allowed domain access to ssh and gdm as well as tty automatically, and that the moded to those files are to lock them back downn?


  23. Hi, Dave,
    It looks like the password-auth file is being used instead of system-auth. If you make those changes in password-auth instead of in system-auth (that is:
    auth sufficient use_first_pass
    account [default=bad success=ok user_unknown=ignore]
    password sufficient use_authtok
    session optional
    does that fix things up for you? You'd want to remove those lines from system-auth; I'm not sure what effect (if any) there'd be from having those called twice in the chain.

    Here's hoping it's that simple! :)

  24. Lane:

    Before I continue, thanks again. Can you recommend a good readable explanation of setting up PAM? I've done the usual googling, found a number of links, but haven't come up with a nice clean overview.

    So back to our story.... I actually made a similar discovery, i.e, password-auth-ac and system-auth-ac (which are the linked references from password-auth and system-auth) are 100% exact idebtical content, so I altered both files with the same changes.

    Once I did that, I am able to login any AD account via tty, Gnome Desktop, and SSH.

    I'm still trying to workthru applying restrictions now. It's a bit more difficult to explain the changes I made and failed with in a postback, so here's a URL with the contents of all this files:

    Based on your examples, I'm assuming that my restrictions belong at the end of the "account" section, but bombing out.

    For example, if I add

    account required user = DOMAIN\user1

    to the sshd file immediately after the account, but before the password section of the file , when I try to login with those credentials, not only do I fail to start a session, the server immdiately closes the session. It also kills the session if I try to use a differnt AD account, (although it will still allow a local account login).

    In the words of Yule Brenner... "Eeez a puzzlement!"


  25. Hmmm... looks like again I failed to post back. Mmm.

    Thanks again for the help. I did discover that system-auth and password-auth (actually password-auth-ac and system-auth-ac) are identical files. If i mirrored the changes into both, I am able to login using any AD account via tty, SSH or Gnome.

    The restrictions part is where I am getting hung up. FYI, this link shows you wha tthe unedited files look like, for refernce:

    By way of example, if I append "account sufficient user = DOMAIN\user" after the "account include password-auth" line, and then ssh (via putty) with that account, upon entering the correct password, my putty session is killed "unexpectedly" by the server.

    I also tried to simplify by directly editing the password-auth field (since that is what appears to be called by sshd), both above and below the account required line, but all instances get the same result for AD credentials .... i.e., the same server disconnected message.

    Sorry to lean on you so much, but the docs out there are really obtuse. I've googled quite a few references, and haven't come up with anything that explains it all with sufficient clarity, espcially the whole chain of sufficient/requires/ etc.


  26. Hi, Dave,
    I notice one thing off the bat: the sshd and gdm files each reference different auth files: sshd is including the password-auth file, while gdm is using the system-auth file. Probably good to notice, which is why I bring it up, but not anything to be concerned about.

    To make sure I'm understanding: authorization through AD is working, now, but you're not able to limit logins. If that's right, that's good, as the hard part should be behind us.

    You're right about documentation. The best I have ever found is here, FWIW. The explanations of the various "required," "requisite," "sufficient," etc. are worth a read.

    So. To the point. I'm understanding right, I'm guessing, that you used the "account required user ingroup ..." or something along those lines as the last account line in the sshd file. So the first place I'd look for some hints is in the /var/log/secure and /var/log/messages logs. You should see something about the disconnection there, and it might point us to the right place.

    I'd also try just allowing a single user to log in with something like
    account [default=1 success=ignore] quiet user = DOMAIN\user

    Try putting this as the first in the line of the account settings, as well.

    That way we're not having to worry with whether the groups are getting enumerated correctly and all that.

    Double check, too, that /etc/nologin doesn't exist. Pretty sure it wouldn't, but that's what looks for, and if it's there, PAM disallows all logins but root.

    Let me know what you see; I think we're pretty close.

  27. Hi Lane,

    Many thanks for this article. I'm 99% of the way there, including having functioning access using Kerberos auth.

    However, it seems as though there's something that's not executing properly to create the home directories automatically.

    If I pre-create the home directory, it works just fine. However, if I expect oddjobd to create it, it doesn't appear to be working. I've set the permissions as you've suggested here.

    [root@hostname home]# ls -al
    total 32
    drwxr-xr-x. 5 root root 4096 Sep 23 22:12 .
    dr-xr-xr-x. 27 root root 4096 Sep 23 21:48 ..
    drwx--x--x. 2 root root 4096 Sep 23 22:12 BBIDM
    drwx------. 2 root root 16384 Jul 18 17:38 lost+found
    drwx--x--x. 2 root root 4096 Sep 23 22:08 PRODUCTION

    The error I am getting in /var/log/messages when this connection failure occurs is:

    Sep 23 23:21:22 hostname smbd[18010]: canonicalize_connect_path failed for service jtidsbury, path /home/BBIDM/jtidsbury

    I've set selinux to permissive mode, so I don't think that could be the issue.

    Any other gotchas I'm missing that would be causing this not to work? It certainly feels like a permissions thing, but I can't find any additional info. Basically, connection is okay, but smb can't find the home directory... and it's not being created upon connecting.

    Many thanks again,

  28. I should add that if I ssh into the server as the same AD username as I was testing with above, the home directory is generated automatically. It's only connecting over smb where the home folder isn't being created.

    If I then try connecting with smb, since the home folder is now present, it's not an issue.


  29. Hi great post, I followed this article and was successfully able to intergrate ad authentication on redhat 6.But I need to know whether it is possible to change the ad password from linux. When I give passwd it asks for current nt password and once I give it ,it ask for new password ,here is the issue however complex I give irrespective of removing the password complexity from Ad I am getting BAD password error.

    Need you help on this


  30. Josh, it sounds like you might need to configure the SMB PAM module. Unfortunately, I've lost my test RHEL servers (but I hope to have them back soon), so I can't give a lot of details. I'll do some digging when those are back up and we'll see what we can find.

    Sunil, if I'm understanding you correctly, it sounds like you're unable to change your domain password, regardless of how complex you make it, and also regardless of the complexity settings in the domain.
    If that's right, I'd assume you're running into a problem with PAM's password checking. That's handled, I believe, with pam_cracklib. What pam_cracklib lines does your system-auth and password-auth have in them?

  31. Leave a +1 button here so I can plus one it. Saved me a bunch of time.

    Also you are missing some steps on oddjob set up =]

  32. Hey, I"m glad it was helpful. I've got +1 set up at the beginning and end of the post.

    Would love to know what I've left out on the oddjob setup; my recollection (it's been awhile, now) is that oddjobd was already running on the (mostly) stock RHEL 6 server I was running this one.

  33. Guys

    I am currently working on authenticating my rhel6 to Win2008 AD. I am following this documentation and I am up to "Join the Domain"

    I managed to join my rhel6 to the domain but when I try wbinfo –g or wbinfo –u, nothing happens. Is there anything that I have missed out. Please help

  34. Hi, Bellyn,
    Do you get any error messages with the wbinfo command? How about in /var/log/messages? Off the top of my head, I think there's also a winbind log file or directory in /var/log... though I don't have a system handy to look at right now.
    Let us know what, if anything, you see there, and we'll see what we can do.

    Thanks! -Lane

  35. This comment has been removed by the author.

  36. @ Lane - Thanks for the promt response

    Apparently I looked at one of the forum and found this line in smb.conf "auth methods = winbind". I put it in my smb.conf for a try and it did work.
    One thing that concerns me is restriction of ssh to a specific group. I tried took out one of the member from the AD group that allowed ssh priviledges, but it still does has ssh rights. I even restart sshd thought that will give me luck, but still the same thing. Any ideas?

  37. Hello Lane,

    I am trying to integrate AD authentication to Cent OS 6 servers. I am running to this error when I tried to join with AD server. I installed both Samba as well as windbind. can you please suggest where I am missing.

    error message :


    # net ads join -U 504783
    Host is not configured as a member server.
    Invalid configuration. Exiting....
    Failed to join domain: This operation is only allowed for the PDC of the doma in.

    configuration file of samba smb.conf under [global] is updated with this info.

    workgroup = ctab
    realm = CTAB.ALPHA.COM
    security = ads
    idmap uid = 7000-500000
    idmap gid = 7000-500000
    template shell = /bin/bash
    template homedir = /home/%U
    winbind use default domain = true
    winbind offline logon = false
    winbind nss info = rfc2307
    idmap config TRD:backend = ad
    idmap config TRD:defauly = yes
    idmap config TRD:range = 70000-500000
    idmap config TRD:schema_mode = rfc2307
    server string = Samba Server Version %y
    I have updated krb5.conf as this


    #more /etc/krb5.conf
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log

    default_realm = CTAB.ALPHA.COM
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

    kdc =
    admin_server =

    [domain_realm] = CTLAB.ALPHA.COM = CTLAB.ALPHA.COM
    I wasnt able to fix it can someone please suggest it.

    1. Hi, Bobby,
      I see a couple of things that might be causing this problem. First, it looks like you've got a couple of different domain names listed here. CTAB appears to be what you're wanting, but later in your smb.conf file you've got this:
      idmap config TRD:backend = ad
      idmap config TRD:defauly = yes
      idmap config TRD:range = 70000-500000
      idmap config TRD:schema_mode = rfc2307

      So I think you need to change TRD to CTAB. I also see different realms listed in your krb5.conf file: CTAB and CTLAB. Those need to be the same.

      Finally, I think there's a typo: default is misspelled in the snippet above.

      Does that get you moving in the right direction?

  38. This comment has been removed by the author.

  39. Great blog. Using rhel 6.2 this does not work modifying /etc/pam.d/system-auth, but it did when putting the same settings in /etc/pam.d/password-auth instead.

    1. Thanks, Jsnyder, I ran into that, and I never updated the post; really appreciate the heads-up!

  40. Thanks for your article.
    I am completely set up my centos 6 for domain authentication, but I have a problem.
    I enter a domain username and password to log into my centos and get this:
    user@myhost:~> ssh domain_user@testhost
    domain_user@testhosts's password:
    Last login: Tue Feb 14 17:35:38 2012 from
    Connection to testhost closed.

    It seems that I successfully enter under my domain account, but immediately go out:
    in /var/log/secure log:

    Feb 14 17:42:52 testhost sshd[1597]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= user=domain_user
    Feb 14 17:42:52 testhost sshd[1597]: pam_winbind(sshd:auth): getting password (0x00000010)
    Feb 14 17:42:52 testhost sshd[1597]: pam_winbind(sshd:auth): pam_get_item returned a password
    Feb 14 17:42:52 testhost sshd[1597]: pam_winbind(sshd:auth): user 'domain_user' granted access
    Feb 14 17:42:52 testhost sshd[1597]: pam_winbind(sshd:account): user 'domain_user' granted access
    Feb 14 17:42:52 testhost sshd[1597]: Accepted password for domain_user from port 36403 ssh2
    !!!! Feb 14 17:42:52 testhost sshd[1597]: pam_unix(sshd:session): session opened for user domain_user by (uid=0)
    !!!! Feb 14 17:42:52 testhost sshd[1600]: Received disconnect from 11: disconnected by user
    Feb 14 17:42:52 testhost sshd[1597]: pam_unix(sshd:session): session closed for user domain_user

  41. fixed:
    need to add in smb.conf:
    template shell = /bin/bash

  42. I realizing this is an old posting, but this blog really helped me. Thanks! Really! I only have one "minor" issue - who doesn't right? The Linux box is now in AD. It can pull AD info with the 'wbinfo' command without issue. It even created a new local Linux home directory upon the first AD user login (big thanks there). But only the Linux root user can perform an 'su - ADDOMAIN\\userid'. Anyone else, including another AD user (which root su'd to) trying to perform an 'su - ADDOMAIN\\userid' receives an "su: incorrect password" error.

    I'm still researching this. We're using a fairly "hardened" 2008R2 Domain. We're thinking it's some compatibility with passing the credentials. I've tried adding "client ntlmv2 auth" in Samba, but that didn't solve anything.

    We're not using SELinux nor any Firewalls on the Linux box, so we can rule that out.

    Any ideas? I'll post back if I solve this myself.

    Thanks for your time.

  43. If I type in the wrong password I do receive "Wrong Password", and I can lock the account if I put in the WRONG password enough times. Hmm.

  44. Well, I found this issue. There was an issue in our /etc/pam.d/system-auth-ac file which caused the anomaly. Apparently we carried over some lock-down from RHEL5 to RHEL6, which some things have changed there, like is now, and some of the options for that module have changed.

    A good learning experience being in the PAM, but scary too.

    test, test, test, and test again. Then document!

    1. Thanks for the update, Chris. PAM is awfully complex, isn't it? Maybe it's worthwhile coming up with a post that has more details on it...

  45. For those asking why doesn't work as expected in creating home directories when accessing the samba shares, the answer is in the smb.conf manpage :

    obey pam restrictions (G)

    When Samba 3.0 is configured to enable PAM support (i.e. --with-pam), this parameter will control whether or not Samba should obey PAM´s account and session management
    directives. The default behavior is to use PAM for clear text authentication only and to ignore any account or session management. Note that Samba always ignores PAM for
    authentication in the case of encrypt passwords = yes. The reason is that PAM modules cannot support the challenge/response authentication mechanism needed in the presence of
    SMB password encryption.

    Default: obey pam restrictions = no

    ==> so the solution is to add the following line to the global section of smb.conf and restart samba

    obey pam restrictions = yes

  46. This comment has been removed by the author.

  47. Lane,

    Thanks for the great walk through. I just used this to connect a CentOS 6.3 VM to Windows Server 2012 ADS. Just in case anyone was wondering no issues.

  48. Thanks for this. This is great info you have provided.
    The only question i have is Ive added the following line to my sodoers file and it does not seem to be using this group. Any one have an idea?

    %[]\\[groupname] ALL=(ALL) ALL

  49. Hey,

    I'm having some AD authencticated user to my servers. At times, the AD users are not able to login and I need to restart the winbind service to fix the issue.

    What causing the issue?
    is that caching?

    1. Hey, SaiSundar. I've run into this same problem with some of my systems, and I'm honestly not sure what's happening there. In the months since, have you run into a solution?


Thanks for leaving a comment!