Re: please help with MS AD -> UNIX trust

["Douglas E. Engert" <deengert@anl.gov>]

vadim wrote:
> Hi Douglas,
> 
> thanx a lot for replying me! Really!
> 
> You are abs. presize saying that I expect user once authenticated in
> realm A (Active Directory) to ssh into realm B (Heimdal or MIT) without
> supplying his password again based on trust definition between two
> realms.
> 
> I however doubt a bit in what you saying that the problem is in mapping
> of kerberos principal to unix account (if it is that what you mean). I
> doubt in it, because in OpenSSH server log I see that 
> 
> "gssapi-with-mic failed".

What else does it say.

> 
> At this stage sshd does not do anything with pam or similar. This makes
> me to feel bad as I don't understand how "gssapi-with-mic" could fail if

No, but the ssh_gssapi_krb5_userok in gss-serv-krb5.c calls the krb5_kuserok
routine that checks if the "client" (u@realm) is allowed to login  and
use local account "name".

PAM is not involved with the authentication when GSSAPI is used.
PAM is called later for a session which can be used to get an AFS token
using the delegated redentials, i.e. forwarded kerberos tickets.

> 
> 1) user from realm A could obtain ticket form sshd in realm B via trust
> definitions between realms A and B.
> 

In this case the user u@A wold have a TGT for his own realm
   krbtgt/A@A
This would be used to obtain a cross realm ticket from realm A for realm B:
   krbtgt/B@A
This is then used with realm B to get a service ticket for the host in realm B
   host/<FQDN>@B
This is then used by the GSSAPI to authenticate.


So you problem could be in how the cross realm is setup, i.e. if
the keys dont match the krbtgt/B@A might not be accepted by B.

If you look at the logs for the realm B KDCs does it issue the
ticket host/<FQDN>@B to user U@A ?


Or it could be the krb5_kuserok failing as the .k5login is not
allowing it.

> 2) user can ssh into realm B if it logged into realm B directly.
> 
> I was looking in internet for information about possible difficulties
> when trying to establish trust between UNIX KDC and AD. People write a
> lot about salts and supported encription types. I am afraid I am
> struggling with something similar ... I however could not find any
> "ultimative" guide to what I am trying to do ...

salts are used in the string_to_key functions when generating a
key from a password. This might be a problem depending on how
you setup the cross realm trust if you did it by typing in
a password on both sides. But See:

http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp

This is the ultimate guide. It still applies to W2003. The ktpass in 2003
has more options.


> Any suggestion?
> 
> Thanx a lot again, vadim tarassov.
> 
> On Thu, 2005-06-02 at 13:25 -0500, Douglas E. Engert wrote:
> 
>>vadim wrote:
>>
>>
>>>Hallo everybody,
>>>
>>>Could you please point stupid me to the right piece of documentation?
>>>
>>>I've build Kerberos realm, where KDC is MS AD, servers are OpenSSH and
>>>OpenLDAP on Solaris 8, clients are on Solaris and Cygwin. I have used
>>>GSSAPI implementation from Heimdal and MIT with equal success -
>>>everything worked just perfectly!
>>>
>>>Now for some odd reasons I have to build pure UNIX realm and to
>>>establish one-way trust, where UNIX realm trusts AD, and users once
>>>logged into the AD realm, should be able also to logged into the UNIX
>>>realm.
>>
>>You mean "users once logged into the AD realm, should be able also to
>>logged into servers in the UNIX realm."
>>             ^^^^^^^^^^^
>>
>>>I have tried both Heimdal 0.6.4 and MIT 1.4.1 as UNIX realm, and in both
>>>cases I have the same result with OpenSSH:
>>>
>>>1) assuming that AD realm is called A, and UNIX realm is called B,
>>>client obtains TGT for realm A.
>>>2) trying to ssh into realm B client gets ticket 
>>>krbtgt/B@A
>>>3) client gets ticket host/whatsoever@B
>>>
>>>and at this moment GSSAPI fails to establish context between client and
>>>server SSH.
>>>
>>>Since both Heimdal and MIT behaves exactly in the same manner with
>>>several versions of OpenSSH (from 3.8.1 to 4.0), and I have no problems
>>>with AD and Heimdal/MIT if not trying them to trust each other, I am
>>>absolutely sure that I've missed right documentation ...
>>>
>>>Can you please tell me where I could dig futher? 
>>
>>
>>Look for auth_to_local in krb5.conf and .k5login file.
>>These map a principal to a local unix acocunt. By default
>>uses in the host realm are assumed to map to local acocunts.
>>But you are now using cross realm.
>>
>>The host/whatsover@B needs to know that a foreign principal, u@A is
>>allowed to use the local account u.
>>
>>
>>>Thanx a lot and best regards, vadim tarassov.
>>>
>>

-- 

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