Linux : krb5 and pam - Kerberos

This is a discussion on Linux : krb5 and pam - Kerberos ; Hello, 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Linux : krb5 and pam

  1. Linux : krb5 and pam

    Hello,

    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.

    The pam_krb5.so module in /etc/pam.d/system-auth is set to
    "sufficient". I have tried to add another entry:

    account sufficient /lib/security/$ISA/pam_krb5.so.0
    account sufficient /lib/security/$ISA/pam_krb5.so.0\
    realm=not.my.default

    But when I try to authenticate as a user from the non-default domain I
    get an error that the user cannot be found in the Kerberos database.
    Users from the default_realm are able to authenticate. It seems the
    stack stops at the first entry and returns a status OK to PAM when it is
    executed. The pam_krb5 module itself however does not attempt to try the
    other realm as defined in /etc/krb5.conf. There is a similar setup we
    have on Solaris hosts that does actually work.

    I am not quite sure whether this is a PAM or a pam_krb5 issue. Does
    anyone have any suggestions or ideas how to solve this?

    Thanks so far,

    Quinten

  2. Re: Linux : krb5 and pam

    On 2006-03-30 01:21:04 +0200, Quinten 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?

    > The pam_krb5.so module in /etc/pam.d/system-auth is set to
    > "sufficient". I have tried to add another entry:
    >
    > account sufficient /lib/security/$ISA/pam_krb5.so.0
    > account sufficient /lib/security/$ISA/pam_krb5.so.0\ realm=not.my.default


    Is that a backslash?

    > There is a similar setup we have on Solaris hosts that does actually work.


    Similar? How? What is the difference?

    > I am not quite sure whether this is a PAM or a pam_krb5 issue. Does
    > anyone have any suggestions or ideas how to solve this?


    Post more informations, pam settings, krb5.conf on both sides, ...

    --
    Sensei

    The optimist thinks this is the best of all possible worlds.
    The pessimist fears it is true. [J. Robert Oppenheimer]


  3. Re: Linux : krb5 and pam

    Sensei schreef:
    > On 2006-03-30 01:21:04 +0200, Quinten 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?


    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.

    >
    >> The pam_krb5.so module in /etc/pam.d/system-auth is set to
    >> "sufficient". I have tried to add another entry:
    >>
    >> account sufficient /lib/security/$ISA/pam_krb5.so.0
    >> account sufficient /lib/security/$ISA/pam_krb5.so.0\
    >> realm=not.my.default

    >
    > Is that a backslash?


    No, typo in posting, not in the file

    >
    >> There is a similar setup we have on Solaris hosts that does actually
    >> work.

    >
    > Similar? How? What is the difference?


    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.

    >
    >> I am not quite sure whether this is a PAM or a pam_krb5 issue. Does
    >> anyone have any suggestions or ideas how to solve this?

    >
    > Post more informations, pam settings, krb5.conf on both sides, ...


    The settings below, /etc/krb5.conf, /etc/pam.d/system-auth allow users
    from AD1 because it's the default realm in krb5.conf. Users from the AD2
    are not authenticated: verbose debug shows that uid and gid are actually
    found (NIS) but are not found in the kerberos database.

    system-auth
    ===========
    auth required /lib/security/$ISA/pam_env.so
    auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
    auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass
    auth sufficient /usr/local/lib/security/pam_krb5.so
    realm=AD2.DOMAIN.COM use_first_pass

    account required /lib/security/$ISA/pam_unix.so
    account sufficient /lib/security/$ISA/pam_krb5.so debug
    account sufficient /usr/local/lib/security/pam_krb5.so
    realm=AD2.DOMAIN.COM

    password required /lib/security/$ISA/pam_cracklib.so retry=3 type=
    password sufficient /lib/security/$ISA/pam_unix.so nullok
    use_authtok md5 shadow nis
    password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
    password sufficient /usr/local/lib/security/pam_krb5.so
    realm=AD2.DOMAIN.COM use_authtok

    session required /lib/security/$ISA/pam_limits.so
    session required /lib/security/$ISA/pam_unix.so
    session sufficient /lib/security/$ISA/pam_krb5.so debug
    session sufficient /usr/local/lib/security/pam_krb5.so
    realm=AD2.DOMAIN.COM


    krb5.conf
    =========

    [libdefaults]
    default_realm = AD1.DOMAIN.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true

    [realms]
    AD1.DOMAIN.COM = {
    kdc = dc001.ad1.domain.com:88
    kdc = dc003.ad1.domain.com:88
    admin_server = dc001.ad1.domain.com:749
    kpasswd_protocol = SET_CHANGE
    }

    AD2.DOMAIN.COM = {
    kdc = dc001.ad2.domain.com:88
    kdc = dc002.ad2.domain.com:88
    admin_server = dc001.ad2.domain.com:749
    kpasswd_protocol = SET_CHANGE
    }

    [domain_realm]
    .ad1.domain.com = AD1.DOMAIN.COM
    ad1.domain.com = AD1.DOMAIN.COM
    .ad2.domain.com = AD2.DOMAIN.COM
    ad2.domain.com = AD2.DOMAIN.COM

    [appdefaults]
    pam = {
    debug = true
    ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true
    krb4_convert = false
    }
    kinit = {
    renewable = true
    forwardable = true
    }
    login = {
    krb5_get_tickets = true
    }

    messages
    ========
    Mar 28 14:02:28 lsftest001 sshd(pam_unix)[6488]: authentication failure;
    logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=vaughan user=
    user1
    Mar 28 14:02:28 lsftest001 sshd[6488]: pam_krb5: authenticate error:
    Client not found in Kerberos database (-1765328378)
    Mar 28 14:02:28 lsftest001 sshd[6488]: pam_krb5: authentication fails
    for `user1'

    And more verbose:

    Apr 4 12:59:22 lsftest001 sshd(pam_unix)[8484]: authentication failure;
    logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=vaughan user=user2
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: get_config() called
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: Creating a ticket with
    addresses
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: krb4_convert false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: password-changing
    banner set to `Kerberos 5'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: ccache directory set to
    `/tmp'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: making tickets forwardable
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting initial timeout
    to 1
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: keytab file name set to
    `/etc/krb5.keytab'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting maximum timeout
    to 30
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: will only attempt to
    authenticate users when UID >= 0
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: making tickets proxiable
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting renewable
    lifetime to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: required_tgs set to
    `host/lsftest001'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting ticket lifetime
    to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting timeout shift to 2
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: use_authtok false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user_check true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: validate false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn_period 604800
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_sm_authenticate()
    called (prc = Success)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: default Kerberos realm
    is `AD1.DOMAIN.COM'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_get_user returned
    `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user is `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: `user2' has uid 35637,
    gid 40
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: attempting to
    authenticate `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: get_int_tkt returned
    Client not found in Kerberos database
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authenticate error:
    Client not found in Kerberos database (-1765328378)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authentication fails
    for `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_sm_authenticate
    returning 10 (User not known to the underlying authentication module)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: get_config() called
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: Creating a ticket with
    addresses
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: krb4_convert false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: password-changing
    banner set to `Kerberos 5'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: ccache directory set to
    `/tmp'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: making tickets forwardable
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting initial timeout
    to 1
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: keytab file name set to
    `/etc/krb5.keytab'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting maximum timeout
    to 30
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: will only attempt to
    authenticate users when UID >= 0
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: making tickets proxiable
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting renewable
    lifetime to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: required_tgs set to
    `host/lsftest001'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting ticket lifetime
    to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting timeout shift to 2
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: use_authtok false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user_check true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: validate false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn_period 604800
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_sm_authenticate()
    called (prc = Success)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: default Kerberos realm
    is `AD2.DOMAIN.COM'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_get_user returned
    `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user is `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: `user2' has uid 35637,
    gid 40
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: attempting to
    authenticate `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: get_int_tkt returned
    Client not found in Kerberos database
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authenticate error:
    Client not found in Kerberos database (-1765328378)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authentication fails
    for `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: making tickets proxiable
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting renewable
    lifetime to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: required_tgs set to
    `host/lsftest001'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting ticket lifetime
    to 36000
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: setting timeout shift to 2
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: use_authtok false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user_check true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: validate false
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn true
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: warn_period 604800
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_sm_authenticate()
    called (prc = Success)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: default Kerberos realm
    is `AD2.DOMAIN.COM'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: pam_get_user returned
    `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: user is `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: `user2' has uid 35637,
    gid 40
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: attempting to
    authenticate `user2'
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: get_int_tkt returned
    Client not found in Kerberos database
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authenticate error:
    Client not found in Kerberos database (-1765328378)
    Apr 4 12:59:22 lsftest001 sshd[8484]: pam_krb5: authentication fails
    for `user2'


    thanks,
    Quinten

  4. Re: Linux : krb5 and pam

    On 2006-04-04 17:22:04 +0200, Quinten said:

    > Sensei schreef:
    >> On 2006-03-30 01:21:04 +0200, Quinten 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?

    >
    > 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).

    > 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?

    > [libdefaults]
    > default_realm = AD1.DOMAIN.COM
    > dns_lookup_realm = true
    > dns_lookup_kdc = true
    >
    > [realms]
    > AD1.DOMAIN.COM = {
    > kdc = dc001.ad1.domain.com:88
    > kdc = dc003.ad1.domain.com:88
    > admin_server = dc001.ad1.domain.com:749
    > kpasswd_protocol = SET_CHANGE
    > }
    >
    > AD2.DOMAIN.COM = {
    > kdc = dc001.ad2.domain.com:88
    > kdc = dc002.ad2.domain.com:88
    > admin_server = dc001.ad2.domain.com:749
    > kpasswd_protocol = SET_CHANGE
    > }
    >
    > [domain_realm]
    > .ad1.domain.com = AD1.DOMAIN.COM
    > ad1.domain.com = AD1.DOMAIN.COM
    > .ad2.domain.com = AD2.DOMAIN.COM
    > ad2.domain.com = AD2.DOMAIN.COM
    >
    > [appdefaults]
    > pam = {
    > debug = true
    > ticket_lifetime = 36000
    > renew_lifetime = 36000
    > forwardable = true
    > krb4_convert = false
    > }
    > kinit = {
    > renewable = true
    > forwardable = true
    > }
    > 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?


    --
    Sensei

    The optimist thinks this is the best of all possible worlds.
    The pessimist fears it is true. [J. Robert Oppenheimer]


  5. Re: Linux : krb5 and pam

    Sensei schreef:
    > On 2006-04-04 17:22:04 +0200, Quinten said:
    >
    >> Sensei schreef:
    >>> On 2006-03-30 01:21:04 +0200, Quinten 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]


    88

    >> 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.

  6. Re: Linux : krb5 and pam

    On 2006-04-11 01:37:06 +0200, Quinten 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
    user1@REALM1 as well as user2@REALM2. 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/FQDN@REALM1 in the file? Do you have host/FQDN@REALM2? 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

    > 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

    The optimist thinks this is the best of all possible worlds.
    The pessimist fears it is true. [J. Robert Oppenheimer]


  7. Re: Linux : krb5 and pam



    On Tuesday, April 11, 2006 08:40:10 PM +0200 Sensei
    wrote:

    > 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.


    Note that neither ntpdate-at-boot nor a cron job that runs ntpdate once in
    a while really count as "running NTP". A real NTP client needs to be
    running continuously, not just for a few seconds once in a while. Over
    time it will establish an ideal clock which closely tracks the upstream NTP
    servers. It will then correct the system clock by slowly adjusting its
    rate, ultimately leaving it running at something resembling the correct
    rate. Just running ntpdate cannot do this -- it's not running long enough
    to get an idea of how far off-frequency the system clock is.

    -- Jeffrey T. Hutzelman (N3NHS)
    Sr. Research Systems Programmer
    School of Computer Science - Research Computing Facility
    Carnegie Mellon University - Pittsburgh, PA

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: Linux : krb5 and pam

    On 2006-04-12 18:52:24 +0200, jhutz@cmu.edu (Jeffrey Hutzelman) said:

    >> 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.

    >
    > Note that neither ntpdate-at-boot nor a cron job that runs ntpdate once
    > in a while really count as "running NTP". A real NTP client needs to
    > be running continuously, not just for a few seconds once in a while.
    > Over time it will establish an ideal clock which closely tracks the
    > upstream NTP servers. It will then correct the system clock by slowly
    > adjusting its rate, ultimately leaving it running at something
    > resembling the correct rate. Just running ntpdate cannot do this --
    > it's not running long enough to get an idea of how far off-frequency
    > the system clock is.


    Yes, but an hourly cron job has the great advantage of sending very few
    packets over the network, while a real ntp client increases this
    traffic. Client-only workstations are not so important to us as
    servers. Anyway, I can be entirely missing something...

    --
    Sensei

    The optimist thinks this is the best of all possible worlds.
    The pessimist fears it is true. [J. Robert Oppenheimer]


  9. Re: Linux : krb5 and pam

    Sensei writes:

    >Yes, but an hourly cron job has the great advantage of sending very few
    >packets over the network, while a real ntp client increases this
    >traffic. Client-only workstations are not so important to us as
    >servers. Anyway, I can be entirely missing something...


    So use broadcast/multicast NTP.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  10. Re: Linux : krb5 and pam

    On 2006-04-12 21:21:11 +0200, Casper H.S. Dik said:

    > Sensei writes:
    >
    >> Yes, but an hourly cron job has the great advantage of sending very few
    >> packets over the network, while a real ntp client increases this
    >> traffic. Client-only workstations are not so important to us as
    >> servers. Anyway, I can be entirely missing something...

    >
    > So use broadcast/multicast NTP.


    Yes, but using a pure ntp solution instead of a cron ntpdate job, how
    different is the traffic? Having N clients and one server, I have N
    requests every hour. What about the other one? If it's less stressing,
    I'd change all the clients to this solution...

    --
    Sensei

    The optimist thinks this is the best of all possible worlds.
    The pessimist fears it is true. [J. Robert Oppenheimer]


+ Reply to Thread