On Mon, Feb 07, 2011 at 11:36:50AM +1100, Jean-Yves Avenard wrote: > I have read the MIT documentation and created on both kdc > krbtgt/[email protected] > krbtgt/[email protected] > > I then edited the kerberos krb5.conf with the appropriate capaths and > configured AD to accept M.DOMAIN.COM issued tickets. > > What I'm unclear about however, is do I need to configure all kerberos > clients in a similar fashion or is this done only on the 2 kdcs ? > > In particular, I have a FreeBSD server running MIT krb5 1.9 with > mod_auth_kerb . It is set to accept M.DOMAIN.COM realm . Do I need to > explicitely configures it to accept MEL.DOMAIN.COM realm, or because > the two kdcs are configured to accept each other it will then be > automatic ?
Depends what you mean. The *authentication* should just work. Someone in MEL.DOMAIN.COM will be able to get a ticket for host/[email protected], which that server will be able to decrypt using its M.DOMAIN.COM keytab. However you then may have an issue with *authorization*. For example, if you ssh as "user" to freebsd.server, by default sshd will only authorize the login for someone with a ticket "[email protected]" (i.e. the realm of the server itself) Solution 1: you can put [email protected] in ~user/.k5login (or indeed, any kerberos principals you want to be able to login as 'user'). Easy to do, but doesn't scale well if you keep having to add and remove users across all hosts. Solution 2: you can map all [email protected] to [email protected] In krb5.conf (on the FreeBSD server) this would be something like: [realms] M.DOMAIN.COM = { auth_to_local = RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$// auth_to_local = DEFAULT } WARNING: not tested. You need to triple-check that's right, as it could open you up to various holes if not correct. The syntax is interesting, to say the least. Also, you need to make sure that [email protected] and [email protected] are never two different people. But it's a one-off config change on each host. Solution 3: I don't know, maybe other people on this list have some ideas? Regards, Brian. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
