pam_krb5 checks if the kdc you talk to is not a fake by using the host principal in the default keytab. Look at the traffic on port 88 with ethereal and you should see a tgt request for host/server-fqdn. Some pam modules have an option to not do this verification, check your man pages.
Regards Markus "Sensei" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 2006-08-10 15:41:52 +0200, "Jesper Angelo" <[EMAIL PROTECTED]> said: > >> I have trimmed down the configs heavily, so now I still can't login, >> but at least I get a login incorrect. Lets see... >> >>> Clear the auth log and login as I said /locally/ with a /pure/ /local/ >>> user. See what happens working with this user. If you can work and >>> you're not kicked out, then kinit to a principal, noting what klist >>> (klist -aef --- if you want). >> >> Local login works (login as 'newbie'), which show in logs as: >> ============================================================ >> krbtest login: newbie >> Password for newbie: (local password typed in) >> --[LOG]----------------------------------------------------- >> Aug 10 15:28:14 krbtest login[1123]: (pam_unix) session opened for user >> newbie by LOGIN(uid=0) >> ============================================================ >> >> Then kinit to user 'guru' on AD (AD reports user authenticated): >> ============================================================ >> [EMAIL PROTECTED]:~$ kinit guru >> Password for [EMAIL PROTECTED]: >> [EMAIL PROTECTED]:~$ >> --[LOG]----------------------------------------------------- >> (nothing happens) >> ============================================================ > > Should be so. > >> klist for user shows: >> ============================================================ >> [EMAIL PROTECTED]:~$ klist -aef >> Ticket cache: FILE:/tmp/krb5cc_1001 >> Default principal: [EMAIL PROTECTED] >> >> Valid starting Expires Service principal >> 08/10/06 15:32:27 08/11/06 01:30:45 >> krbtgt/[EMAIL PROTECTED] >> renew until 08/11/06 01:32:27, Flags: RIA >> Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5 >> Addresses: (none) >> >> >> Kerberos 4 ticket cache: /tmp/tkt1001 >> klist: You have no tickets cached >> [EMAIL PROTECTED]:~$ >> --[LOG]----------------------------------------------------- >> (nothing happens) >> ============================================================ > > Again, no logging is ever provided for these commands. > >> Keytab shows (ran as root): >> ============================================================ >> krbtest:~# klist -kt >> Keytab name: FILE:/etc/krb5.keytab >> KVNO Timestamp Principal >> ---- ----------------- >> -------------------------------------------------------- >> 5 01/01/70 01:00:00 host/[EMAIL PROTECTED] >> krbtest:~# >> --[LOG]----------------------------------------------------- >> (nothing happens) >> ============================================================ >> >> So far so good. > > Yep, it seems that you can get tickets. Good. > >> If I then logout, adds krb to login in PAM, and logs >> in, I get: >> ============================================================ >> krbtest login: newbie >> Password for [EMAIL PROTECTED]: (ad password for newbie typed in) >> Login incorrect >> >> Login: >> --[LOG]----------------------------------------------------- >> Aug 10 15:37:17 krbtest login[1151]: pam_krb5: >> pam_sm_authenticate(login newbie): entry: >> Aug 10 15:37:22 krbtest login[1151]: pam_krb5: verify_krb_v5_tgt(): >> krb5_mk_req(): Server not found in Kerberos database >> Aug 10 15:37:22 krbtest login[1151]: pam_krb5: >> pam_sm_authenticate(login newbie): exit: failure >> Aug 10 15:37:22 krbtest login[1151]: (pam_unix) authentication failure; >> logname=LOGIN uid=0 euid=0 tty=tty1 ruser= rhost= user=newbie >> Aug 10 15:37:25 krbtest login[1151]: FAILED LOGIN (1) on `tty1' FOR >> `newbie', Permission denied >> ============================================================ > > Trying to use pam_krb5 and you get a nice > > ``server not found''... > > A question: are the keytab entries /completely/ matching the server > entries? PAM is a service while kinit is not, and so it's really sensible > to this errors. Also remember that the keytab must use a FQDN. > >> [libdefaults] >> debug = true >> default_realm = BORSEN-ONLINE.DK >> dns_lookup_realm = true >> dns_lookup_kdc = true >> ticket_lifetime = 24000 >> >> [realms] >> BORSEN-ONLINE.DK = { >> kdc = adtest.borsen-online.dk >> admin_server = adtest.borsen-online.dk >> # default_domain = borsen-online.dk >> kpasswd_protocol= SET_CHANGE >> } >> >> [domain_realm] >> .borsen-online.dk = BORSEN-ONLINE.DK >> # borsen-online.dk = BORSEN-ONLINE.DK > > Depending on what software you are using, domain_realm could not work. I > found systems where I needed BOTH mappings, and systems in which i needed > none of them. > > By 2 cents, sorry :) > > -- > 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