On 2006-04-11 01:37:06 +0200, Quinten <[EMAIL PROTECTED]> said: >>>> Naive question... can you kinit the NOT_DEFAULT_REALM? >>> > > Buck: To clear out my misconceptions on the definition of > authentication, I meant logging on with SSH from another machine. I am > indeed able to kinit succesfully as both users from both domains when I > log on locally as one of the users. See my writing below.
Ok. >> This is probably something bad with your configuration. You *MUST* be >> able to kinit default realm principals (without @REALM) and non-default >> ones (with @REALM). >> > > I did some more testing by su-ing to users that are members from > different domains. The su is not kerberized (ksu) so they won't receive > a ticket. Then I performed the kinit command and was able to get a > ticket for each user from each domain. So I think it is save to > conclude that it is not the kerberos config that has problems. So let's say, you log in as root, and then you can kinit as [EMAIL PROTECTED] as well as [EMAIL PROTECTED] This involves pam_unix.so and pure kinit, and makes pretty sure as you say, krb5.conf is ok as well as the cryptography for each user. > Logging on to the server by using SSH however, allows only one user > from one domain to be logged on: the user from the domain that is set > default in the /etc/krb5.conf. Now, let's talk about the host keytab files. Do you have host/[EMAIL PROTECTED] in the file? Do you have host/[EMAIL PROTECTED] What about their KVNOs? I forgot that once and I wasn't able to login again via ssh. > I heavily suspect the pam_krb5 module in this case; it is able to > perform kerberos authentication for the default domain. For the non > default domain the debug output in /var/adm/messages is able to get the > user from the kerberos database but then fails to validate the password. > > I will setup a tcpdump to see which kdc it is trying to contact in the > latter case. And recompile some pam_krb5 modules to see wether there > will be differences. I will let you know. Well, I hope you forgot the keytabs and with that you have everything running smoothly, otherwise... well, a tcpdump should be fine :) Before that, why don't you add ``debug'' to the pam_krb5.so lines in your pam settings? It should work for auth and password only (if my memory doesn't fail), so you will se a more verbose log and hopefully some hints. >> PS. I ask, don't be angry: are all the times set correctly with some >> ntp based solution? >> >> > > *This makes me go bezerk completely* :-). Have mercy :D > It is a very valid question because it will cause weird problems when > the local times differ too much. But we have set NTP for all servers > and clients. Good. One thing I noticed on many clients here is that an ntpdate at boot solution is not good, since it can produce large time drifts if you don't reboot the clients often. A cron job was my solution. Just my 2 cents... I hope it will help! -- Sensei <[EMAIL PROTECTED]> The optimist thinks this is the best of all possible worlds. The pessimist fears it is true. [J. Robert Oppenheimer] ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
