Find the answer to your Linux question:
Results 1 to 4 of 4
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Winbind with Kerberos Woes

    I hope this is the right forum for this issue, but please move it if not.

    I've been given the task of integrating some Red Hat Enterprise Linux 6 Update 3 servers with our MS Active Directory, which I also administer.

    I'm pleased to say I've suceeded in getting logons (local and ssh) working with winbind/samba, using the rid backend for id mapping, and it's all working well.

    My question though is about the authentication mechanisms in use. All of the guides, for example Red Hat's own one (Google: red hat linux active directory), talk about Kerberos, and have you configuring krb5.conf and testing it with kinit/klist etc.

    This is fine, but when it comes to the process of logging on to the machine with an AD account, Kerberos isn't used at all it appears. NTLM (the horror) is what's doing the authentication.

    I came up against this fact because in our domain we restrict the use of NTLMv1 because it's scary from a security standpoint. Logins via Winbind/Samba failed because they were trying to use NTLMv1. I configured winbind to use NTLMv2 using 'client ntlmv2 auth = yes' in smb.conf, and bingo, it worked!

    In fact, I found that I could completely disable and uninstall Kerberos from the machine, and the AD logon still worked, through NTLM of course.

    So I now have two questions:

    1) Why do all the guides talk about kerberos, when you don't need it, nor is it even used by default, for winbind based authentication? I'm sure there is a reason, the authors are not stupid, so I'd like to know what that reason is.

    2) More importantly, is there any way to force Kerberos authentication and get rid of the dependency on NTLM, which even MS themselves are starting to discourage now? I looked at my pam.d directory and experimented a little with pam_krb5 directives but I couldn't get it working. I'd appreciate a pointer in the right direction from someone who knows the full story really.

    Looking forward to any responses...


  2. #2
    Having been down this road many times, I can sympathize. I usually use krb to verify I can communicate with the domain and *join* it. Creating a principle for Samba to auth users via Kerberos is additional work/steps. An example of nsswitch/pam for krb auth once setup is done is here. But in truth, most find it easier to "fall back" on Winbind for auth duties. This is changing, as NTLMv1 continues to be restricted/removed. You may also want to look at Samba 4, which just went release-ready on 12/11 and supports NTLMv2.

    Edit: I have not used this, but just ran across it - a modified pam_krb5 to dynamically query AD. It appears to clean up/bypass a good portion of the LDAP config steps.

  3. #3
    Hi, thanks for the reply.

    I've got NTLMv2 working, so I'm happy with the security side of things. I'm just curious really about how these things are implemented by Samba and Winbind.

    At the moment, I'm concluding that Winbind relies on NTLM and I'm going to have to live with it. I could of course use LDAP/Kerberos for authentication instead of Winbind, but then I'd have to do a lot more administration inside AD and mess about with keytabs and such, which seems like too much additional administration really.

    I'll keep this on the back burner. Samba 4 isn't an option for this project as I'm stuck with what RHEL6 ships with, but I'll certainly have a play with it at home for investigation. Maybe they've already fixed this

  4. $spacer_open
  5. #4
    Well well, I don't know what's changed, but I'm no longer seeing this behaviour. All logon authentication now seems to be happening using Kerberos and not NTLM.

    I assume kerberos was being attempted all along, but was failing for some reason and NTLM was being used as a failback. I don't know why it was failing though, since kinit was working fine.

    While researching, I did dig up some options that seem to control this behaviour in pam_winbind.conf, but interestingly I still didn't actually need to change any of them in order to see it now using kerberos.

    Sometime when I'm bored I'll set this up from scratch again in the lab and see whether I see the same weird behaviour.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts