Thanks to all of you guys for making this an exciting thread. I have learned a great deal about cross realm authentication and it will help me approach my customers much more prepared.
On another note (and with gratitude), I wrote up a tutorial on how to integrate Solaris 9 Kerberos clients with an MS Win2003 AD. Part of my job is to figure out some of these complex interoperability issues, teach them to clients, and document my work. I am new to this list and I am not sure if Microsoft is a dirty word in these parts. In any case, I offer this tutorial (and many others) in thanks for your help: www.ufsdump.org Darren > * Douglas E. Engert ([EMAIL PROTECTED]) wrote: >> >If my understanding is correct, to establish cross-realm authentication >> we >> >need to follow these steps : >> > >> > >> > 1 - Admin in EXAMPLE.COM creates the principal >> krbtgt/[EMAIL PROTECTED] >> >> Yes. >> >> > >> >2 - Using the same key , admin in EXAMPLE1.COM creates >> >krbtgt/[EMAIL PROTECTED] >> >> No. Using same key, admin in EXAMPLE1.COM creates >> krbtgt/[EMAIL PROTECTED] >> Same principal name in both realms. (This is the only place where a >> principal in the >> database in not for the same realm, it is used as if it was in a keytab >> file.) >> >> The above gives you one way trust, if you want cross realm to work the >> other way, >> then using a new key, both admins create krbgt/[EMAIL PROTECTED] >> in >> thier >> realms with this new key. >> >> > >> >3- when a user in EX1.COM asks for a service in EX.COM, his KDC give >> this >> >client a Service Ticket for krbtgt/[EMAIL PROTECTED] encrypted >> using >> >the key of krbtgt/[EMAIL PROTECTED] >> > >> >> Yes. >> >> >4- TGS in EX.COM can decrypt this ticket using the key of the principal >> >krbtgt/[EMAIL PROTECTED] which is the same key as the principal >> >krbtgt/[EMAIL PROTECTED] >> >> No it uses the same principal, krbtgt/[EMAIL PROTECTED] > > Ok, I think I got it now , thanks ! > >> >>If the KDCs don't share keys, you can't do cross realm. There must >> >>be a trusted path between the user's realm and the server's realm >> >>by having two or more realms share keys. >> > >> > >> >In the question above, I try to understand the motivations that made >> the >> >cross-realm operations the way they are. >> > >> >I meant that why the KDCs just communicate with each others to get the >> TGT >> >for the client. >> >> The KDCs do NOT communicate with each other. The client contacts a KDC >> in a realm to get a ticket for the next realm. > > Yes, I think I miss expressed my self. I meant that if ever the protocol > that allows a client to get a TGT for a remote realm, was transparent to > the > client it would be good. > >> In the MIT release there is a test program t_walk_rtree that can >> show what TGTs the client would need to get. >> >> ./t_walk_rtree A.B.X.Y.Z C.D.X.Y.Z >> krbtgt/[EMAIL PROTECTED] >> krbtgt/[EMAIL PROTECTED] >> krbtgt/[EMAIL PROTECTED] >> krbtgt/[EMAIL PROTECTED] >> krbtgt/[EMAIL PROTECTED] > > I would be happy to try it out. I just need to have a couple of realms :-) > >> >If KDC-A and KDC-B in the realms A and B share keys. Then >> >why does the client need to be involved in getting this TGT and have to >> ask >> >KDC-A and KDC-B respectively. >> > >> >Why not just make the KDC-A and KDC-B exchange messages (in an >> inter-KDC >> >protocol fashion) and get the KDC-A provide the TGT for realm B to the >> >client in realm A. >> > >> >Is such protocol (inter-TGS) seems feasible ? >> >> If you thing you have a better idea, get involved with the IETF krb-wg >> and propose the changes. > > I'm looking forward. > >> >In access networks the access routers need to get the credentials of >> the >> >user before granting him any access. Therefore kerberos based auth is >> not >> >possible in access networks (i.e. to authenticate users before >> providing >> >Internet connectivity). >> >> This sounds like the IAKERB from a few years ago: >> >> Initial and Pass Through Authentication Using Kerberos V5 and the >> GSS-API >> (IAKERB) >> <draft-ietf-cat-iakerb-09.txt> >> >> 1. Abstract >> >> This document defines extensions to the Kerberos protocol >> specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism >> (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for >> services where the KDC is not accessible to the client, but is >> accessible to the application server. Some common scenarios where >> lack of accessibility would occur are when the client does not have >> an IP address prior to authenticating to an access point, the client >> is unable to locate a KDC, or a KDC is behind a firewall. The >> document specifies two protocols to allow a client to exchange KDC >> messages (which are GSS encapsulated) with an IAKERB proxy instead of >> a KDC. >> > > This draft addresses exaclty my point about using kerberos in access > networks. > > > Thank you very much. > > > > > -- > Saber ZRELLI <[EMAIL PROTECTED]> > Japan Advanced Institute of Science and Technology > Center of Information Science > Shinoda Laboratory > url : http://www.jaist.ac.jp/~zrelli > gpg-id : 0x7119EA78 > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
