Hi Greg, > As I understand the enterprise principal name type based on RFC 6806 > section 5, it is intended to convey an email-style alias which should be > looked up in some kind of name service to figure out the actual > principal name and realm for a user. Active Directory contains such a > service; the MIT krb5 KDC does not, unless you use a third-party KDB > module which provides one.
…or find an elegant concept and patch it into an existing one... > (Our LDAP KDB module supports aliases within > a realm, but not aliases which point to other realms.) Yes, I found the is_principal_in_realm() check that is obviously there to weed out funny responses due to aliases in the LDAP store, crossing over the boundaries of realms. > Creating an actual principal entry for an enterprise name doesn't seem > like a good idea. A client which makes an AS request for an enterprise > name should wind up with a ticket for an actual, normal principal name, > not a ticket for the alias. That’s why I would combine it with canonicalisation. That way, the login with an enterprise name is not the normal mode, but it would translate to a “real” principal name. This is not enforced by the KDC and the user should choose to canonicalise, but if someone insisted on a funny name like joe\@example....@example.com then I fail to see hard reasons to stop him...? Thanks, -Rick ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos