[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: please help with MS AD -> UNIX trust
Hallo Douglas,
Thanx a lot again. I have tried to create .k5login file, and it made
actually the trick. You were absolutely right.
Thanx a lot and best regards, vadim tarassov.
On Fri, 2005-06-03 at 09:17 -0500, Douglas E. Engert wrote:
>
> 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.
> >>>
> >>
>
--
vadim <vadim.tarassov@swissonline.ch>