Linux : krb5 and pam

[Quinten]

Sensei schreef:
> On 2006-04-04 17:22:04 +0200, Quinten <quinten at xs4all.nl> said:
> 
>> Sensei schreef:
>>> On 2006-03-30 01:21:04 +0200, Quinten <quinten at xs4all.nl> said:
>>>
>>>>   Our environment is currently using 2 AD/realms. I am trying to set 
>>>> up a RHEL3 host to authenticate users from both realms. If the 
>>>> default_realm in /etc/krb5.conf is set to one realm, the users in 
>>>> the other realm cannot authenticate and vice versa. So there is no 
>>>> issue on any settings, they just seem unable to coexist.
>>>
>>> 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.

>> No, but if I make the other realm default I can. All users from realm, 
>> say AD1, can authenticate if AD1 is default in krb5.conf. All users 
>> from realm, say AD2, can authenticate if AD2 is default in krb5.conf.
> 
> 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.

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.

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.

>> On the Solaris host, a workaround has been established by copying and 
>> renaming the pam_krb5 module and add this module entry in the pam.conf 
>> with the option realm=ad2.domain.com. If the first entry fails 
>> (default realm) pam continues with the second, renamed entry with the 
>> option that overrides the default realm.
> 
> Wow... weird. Have you tried this thing here?
> 

I have, but it did not work.

>> [libdefaults]

8<snip_config>8

>>   login = {
>>    krb5_get_tickets = true
>>   }
> 
> This, apart from default_tgs_enctypes and default_tkt_enctypes (probably 
> you want these to interact with AD smoothly, just google for previous 
> posts), seems good to me.
> 
> The thing we need now is some debug about kinit. This has nothing to do 
> with pam or ssh/pam, you cannot even kinit.
> 
> Can you debug and trace the calls to see what's wrong with your realms 
> and configuration?
> 
> Cheers!
> 
> PS. I ask, don't be angry: are all the times set correctly with some ntp 
> based solution?
> 
> 

*This makes me go bezerk completely* :-).
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.

Tnx 8-)

Q.