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.

/etc/krb5.conf

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 = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
Here we’re defining the kerberos realm and domains. “example.com” will be replaced with your AD domain name. Do note the capitalization; it matters.

/etc/samba/smb.conf

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.

/etc/nsswitch.conf

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 'example.com' [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 https://bugzilla.redhat.com/show_bug.cgi?id=666418, 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 pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_winbind.so account required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session optional pam_oddjob_mkhomedir.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
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.

/etc/pam.d/sshd

#%PAM-1.0 auth required pam_sepermit.so auth include password-auth auth include system-auth account required pam_nologin.so account include system-auth account sufficient pam_localuser.so account required pam_succeed_if.so user ingroup DOMAIN\linuxadmins password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so 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.

/etc/pam.d/gdm

#%PAM-1.0 auth [success=done ignore=ignore default=bad] pam_selinux_permit.so auth required pam_succeed_if.so user != root quiet auth required pam_env.so auth substack system-auth auth optional pam_gnome_keyring.so account required pam_nologin.so account include system-auth account sufficient pam_succeed_if.so user = DOMAIN\user34 account sufficient pam_succeed_if.so user ingroup DOMAIN\linuxadmins account required pam_succeed_if.so user ingroup DOMAIN\domainadmins password include system-auth session required pam_selinux.so close session required pam_loginuid.so session optional pam_console.so session required pam_selinux.so open session optional pam_keyinit.so force revoke session required pam_namespace.so session optional pam_gnome_keyring.so 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.

53 comments:

  1. Great info! Playing with this now.

    ReplyDelete
  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
    -bash-4.1$

    ReplyDelete
  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

    ReplyDelete
  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.

    ReplyDelete
  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.

    thanks,
    Todd

    ReplyDelete
  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.

    ReplyDelete
  7. I've filed a bug for this, BTW.
    https://bugzilla.redhat.com/show_bug.cgi?id=666418

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

    ReplyDelete
  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.

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

    ReplyDelete
  10. @ Al Said

    wbinfo is part of samba-winbind.

    [root@rhel6test ~]# rpm -qf /usr/bin/wbinfo
    samba-winbind-3.5.4-68.el6_0.1.x86_64

    ReplyDelete
  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.

    ReplyDelete
  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!?

    ReplyDelete
  13. Dear Lane

    I was also experiencing problems with the (pam_oddjob_mkhomedir.so) 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.

    DOES NOT WORK FOR ME:
    session required pam_oddjob_mkhomedir.so skel=/etc/skel umask=0077

    WORKS FOR ME:
    session required pam_mkhomedir.so skel=/etc/skel umask=0077

    Cheers
    mayak

    ReplyDelete
  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 ..."

    Thanks!

    ReplyDelete
  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.

    @Eddy,
    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 http://www.ncsa.illinois.edu/UserInfo/Consulting/Security/Kerberos/kerbuse.html for more on the kinit stuff. Let us know what you find!

    ReplyDelete
  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.

    Thanks,

    Eddy

    ReplyDelete
  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!

    ReplyDelete
  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...

    ReplyDelete
  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

    ReplyDelete
  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?

    ReplyDelete
  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
    #%PAM-1.0
    auth required pam_sepermit.so
    auth include password-auth
    account required pam_nologin.so
    account include password-auth
    password include password-auth
    # pam_selinux.so close should be the first session rule
    session required pam_selinux.so close
    session required pam_loginuid.so
    # pam_selinux.so open should only be followed by sessions to be executed in the user context
    session required pam_selinux.so open env_params
    session optional pam_keyinit.so force revoke
    session include password-auth

    ..continued...

    ReplyDelete
  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?


    tHANKS IN ADVANCE!

    ReplyDelete
  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 pam_winbind.so use_first_pass
    account [default=bad success=ok user_unknown=ignore] pam_winbind.so
    password sufficient pam_winbind.so use_authtok
    session optional pam_oddjob_mkhomedir.so
    )
    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! :)

    ReplyDelete
  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:

    http://cl1p.net/abcd123


    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 pam_succeed_if.so 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!"

    Dave

    ReplyDelete
  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:

    http://cl1p.net/abcd123


    By way of example, if I append "account sufficient pam_succeed_if.so 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 pam_permit.so 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.


    Dave

    ReplyDelete
  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] pam_succeed_if.so 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 pam_nologin.so 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.

    ReplyDelete
  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,
    Josh

    ReplyDelete
  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.

    Thanks,
    Josh

    ReplyDelete
  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

    Regards
    Sunil

    ReplyDelete
  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?

    ReplyDelete
  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 =]

    ReplyDelete
  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.

    ReplyDelete
  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

    ReplyDelete
  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

    ReplyDelete
  35. This comment has been removed by the author.

    ReplyDelete
  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?

    ReplyDelete
  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 :


    Code:

    # 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.


    Code:
    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


    Code:

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

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

    [realms]
    CTLAB.ALPHA.COM = {
    kdc = ctab.alpha.com
    admin_server = ctab.alpha.com
    }

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

    ReplyDelete
    Replies
    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?

      Delete
  38. This comment has been removed by the author.

    ReplyDelete
  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.

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

      Delete
  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 192.168.0.100
    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=192.168.0.100 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 192.168.10.100 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 192.168.10.100: 11: disconnected by user
    Feb 14 17:42:52 testhost sshd[1597]: pam_unix(sshd:session): session closed for user domain_user

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

    ReplyDelete
  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.

    ReplyDelete
  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.

    ReplyDelete
  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 pam_tally.so is now pam_tally2.so, 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!

    ReplyDelete
    Replies
    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...

      Delete
  45. For those asking why pam_oddjob_mkhomedir.so 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

    ReplyDelete
  46. This comment has been removed by the author.

    ReplyDelete
  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.

    ReplyDelete
  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?

    %[domain.name]\\[groupname] ALL=(ALL) ALL

    ReplyDelete
  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?

    ReplyDelete
    Replies
    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?

      Delete

Thanks for leaving a comment!