Getting user info via LDAP, authenticating via Kerberos

[Douglas E. Engert]

John Koelndorfer wrote:
> Hello again,
> 
> Firstly, thanks to those who have taken time to shoot an e-mail my way 
> to try and help. It's greatly appreciated.  Secondly, sorry to be 
> sending out another list mail but I notice that the suggestions I got 
> were all more or less the same -- look at PAM. I think I may not have 
> been clear enough in my last e-mail, so I'll try to explain again. I 
> also forgot to include version numbers and attach some config files. 
> Again, my apologies.
> 
> Also, I don't do much in the realm of mailing lists so I'm unsure if it 
> is expected that most people that write in are subscribed. I happen not 
> to be, so please reply directly to my address if you would.
> 
> Our servers are primarily running RHEL4:
> `cat /etc/issue`
> Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
> Kernel \r on an \m
> 
> Some important lib versions (I don't think I missed any but I am far 
> from an expert):
> `rpm -qa | grep krb5`
> krb5-workstation-1.3.4-60.el4
> krb5-auth-dialog-0.2-1
> krb5-libs-1.3.4-60.el4
> pam_krb5-2.1.17-6.el4
> 
> `rpm -q "nss_ldap"`
> nss_ldap-253-5.el4
> 
> Finally, a kernel version:
> `uname -r`
> 2.6.9-78.ELsmp
> 
> The suggestions I got via e-mail were to look at my PAM configuration. 
> What I was attempting to convey before was that I have indeed gone over 
> PAM settings and here's what I have:
> 
> I can successfully get a Kerberos ticket (it is shown in `klist` after 
> login) **if ldap is not listed in nsswitch.conf**. Here's a snippet to 
> show what I mean:
> 
> passwd:     files
> shadow:     files
> group:      files
> 
> The above works. However, I have to create a local user account for the 
> user I want to log in with. This is not something I'd like to have to 
> do. Now, here's a non-working snippet:
> 
> passwd:     files ldap
> shadow:     files ldap
> group:      files ldap
> 
> The above causes `klist` to not show Kerberos tickets (and in fact they 
> aren't retrieved as users cannot access homes). Nothing in the PAM 
> configuration changed in this test.
> 
> I've provided somewhat censored versions of /etc/krb5.conf, 
> /etc/ldap.conf, /etc/pam.d/system-auth, and /etc/nsswitch.conf. I hope 
> these will be helpful if anyone would be kind enough to help. If 
> something else is needed, please do let me know.

Some other things to try to see if nss-ldap is working as expected:

   As root, does getent passwd some-user-in-ldap
   give you the results expected?
   Does it show you a password field?

   As a user, does getent passed some-user-in-ldap
   give you everything but the password?

   Also try the other getent passwd uid, getent group groupname and
   getent group gid.

Since you said ssh is failing, can you start sshd on a different port
with debugging, and see where it fails?


> 
> John Koelndorfer wrote:
>> Hello everyone,
>>
>> I've got a tricky problem that's been gnawing at me for the past few 
>> days or so. First, a little background:
>>
>> We're running an active directory setup with the usual Windows domain 
>> controllers (they're Windows 2000, if it matters) but users' home 
>> directories are stored on a Linux box running Samba. Our other Linux 
>> servers will need to get at these homes for various reasons. Our setup 
>> is fine with NFSv3, but we were looking to gain security and move up 
>> to NFSv4 with Kerberos authentication. NFSv4 won't allow people to 
>> access their home directories without a valid Kerberos ticket for 
>> their principal. If this could be turned off somehow, that'd be one 
>> way to fix this issue (all_squashing to root doesn't sound 
>> particularly appealing) otherwise I need users to be able to get their 
>> Kerberos ticket on login.
>>
>> That works fine as long as ldap is not listed in nsswitch.conf. The 
>> problem is we need to use ldap to fetch user info.
>>
>> So, here's a quick example in case I wasn't clear enough:
>> I ssh to our server using my domain credentials, kdorf and password.
>>
>> If I have a local user account on that machine and ldap is *not* 
>> listed in nsswitch.conf, I can login using my domain password and a 
>> valid Kerberos ticket is fetched for me -- I get access to my home.
>>
>> If I don't have a local account on that machine and ldap *is* listed 
>> in nsswitch.conf, I can login using my domain password but `klist` 
>> shows that I do *not* have a valid Kerberos ticket. Home directory 
>> access is denied.

Does it show any tickets?

As a test to see if the problem is related to the home directory,
in NFS, can you set up a AD user account with the msSFU30HomeDirectory
to point at a local file system, rather then NFS? This
would show if the issues are with LDAP, or the way sshd
uses Kerberos and NFSv4 to access the home directory.


The following is speculation, as I have not tried this...
Since sshd want to use session based accounts, and will set
the KRB5CCNAME=/tmp/krb5cc_uid_xxxxxx
where xxxxx is different for each session.

But the NFS daemons may be expecting Kerberos tickets to be in
the default ticket cache for a user: /tmp/krb5cc_uid
the NFS daemon may not be able to access the home, and
sshd may not be able to change and of the dot files.

AFS has some of the same issues with having to use a ticket
to access home directories as NFSv4 would have. Some of the
dot files may need to be accessed by the daemon before
the login is complete. One is the .k5login file.


>>
>> I need to have valid Kerberos tickets fetched for ldap users. 
>> Alternatively, I would like NFSv4 to not sweat people about Kerberos 
>> tickets to access their homes. Is this possible?

The issue of session based ticket caches vs NFSv4's gssd using
the default ticket cache is one of those issues that may not be
being addressed.

>>
>> Thanks in advance for your help.
>> John
> 
> 
> ------------------------------------------------------------------------
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444