Possibility of not creating host principals and keytabs forWorkstations - Kerberos

This is a discussion on Possibility of not creating host principals and keytabs forWorkstations - Kerberos ; I'm looking for a way to use a combination of kerberos & ldap authentication for (primarily Fedora 8) Linux workstations. My goal is to have an automated install that will allow users to authenticate to kerberos immediately after install, without ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Possibility of not creating host principals and keytabs forWorkstations

  1. Possibility of not creating host principals and keytabs forWorkstations

    I'm looking for a way to use a combination of kerberos & ldap authentication
    for (primarily Fedora 8) Linux workstations. My goal is to have an
    automated install that will allow users to authenticate to kerberos
    immediately after install, without the need to create host principals or
    extract keytabs.

    Right now, when I ssh in, it hangs and I get this with debug turned on:

    Jan 16 09:48:17 bkingkstest1 sshd[2295]: pam_krb5[2295]: trying
    previously-entered password for 'bking', allowing libkrb5 to prompt for more
    Jan 16 09:48:17 bkingkstest1 sshd[2295]: pam_krb5[2295]: authenticating '
    bking@REALM' to 'krbtgt/REALM@REALM'
    Jan 16 09:48:17 bkingkstest1 sshd[2295]: pam_krb5[2295]:
    krb5_get_init_creds_password(krbtgt/REALM@REALM returned 0 (Success)
    Jan 16 09:48:17 bkingkstest1 sshd[2295]: pam_krb5[2295]: got result 0
    (Success)

    Thoughts?

    My (sanitized) krb5.conf:

    [logging]
    default = SYSLOG:ERR:USER

    [libdefaults]
    default_realm = REALM
    dns_lookup_kdc = false
    dns_lookup_realm = false
    noaddresses = true
    validate = false

    [realms]
    EXPERTCITY.COM = {
    kdc = names1.realm
    master_kdc = names0.realm
    admin_server = names0.realm
    auth_to_local = RULE:[2:$1;$2](.*;root)s/;root$//
    auth_to_local = RULE:[2:$1;$2](.*;admin)s/;admin$//

    auth_to_local = DEFAULT
    }

    [domain_realm]
    .realm = REALM

    [appdefaults]
    pam = {
    forwardable = true
    }

    My pam.d/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
    minimum_uid=3000 use_authtok debug
    #auth required /lib/security/$ISA/pam_deny.so

    account required /lib/security/$ISA/pam_unix.so broken_shadow
    account sufficient /lib/security/$ISA/pam_localuser.so
    account sufficient /lib/security/$ISA/pam_krb5.so debug
    account sufficient /lib/security/$ISA/pam_ldap.so debug
    account required /lib/security/$ISA/pam_permit.so

    password requisite /lib/security/$ISA/pam_cracklib.so retry=3
    password sufficient /lib/security/$ISA/pam_unix.so nullok
    use_authtok md5 shadow
    password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
    debug
    password required /lib/security/$ISA/pam_deny.so debug

    session required /lib/security/$ISA/pam_limits.so
    session required /lib/security/$ISA/pam_unix.so
    #session required /lib/security/$ISA/pam_mkhomedir.so
    skel=/etc/skel/ umask=0022
    sauth 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
    minimum_uid=3000 use_authtok debug
    #auth required /lib/security/$ISA/pam_deny.so

    account required /lib/security/$ISA/pam_unix.so broken_shadow
    account sufficient /lib/security/$ISA/pam_localuser.so
    account sufficient /lib/security/$ISA/pam_krb5.so debug
    account sufficient /lib/security/$ISA/pam_ldap.so debug
    account required /lib/security/$ISA/pam_permit.so

    password requisite /lib/security/$ISA/pam_cracklib.so retry=3
    password sufficient /lib/security/$ISA/pam_unix.so nullok
    use_authtok md5 shadow
    password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
    debug
    password required /lib/security/$ISA/pam_deny.so debug

    session required /lib/security/$ISA/pam_limits.so
    session required /lib/security/$ISA/pam_unix.so
    #session required /lib/security/$ISA/pam_mkhomedir.so
    skel=/etc/skel/ umask=0022
    session optional /lib/security/$ISA/pam_krb5.so debug
    session optional /lib/security/$ISA/pam_ldap.so debug
    session optional /lib/security/$ISA/pam_krb5.so debug
    session optional /lib/security/$ISA/pam_ldap.so debug

    Any ideas? Is what I'm trying even possible?

    Thanks,

    --
    Barry King
    barryking93@gmail.com

  2. Re: Possibility of not creating host principals and keytabs for Workstations

    >>>>> "BK" == Barry King writes:

    BK> I'm looking for a way to use a combination of kerberos & ldap
    BK> authentication for (primarily Fedora 8) Linux workstations. My
    BK> goal is to have an automated install that will allow users to
    BK> authenticate to kerberos immediately after install, without the
    BK> need to create host principals or extract keytabs.

    You don't need to create host principals in order for a user to
    authenticate to a Kerberos realm on that host. In fact, if you have your
    SRV and _kerberos RR's in the DNS, the initial /etc/krb5.conf will
    probably let you kinit and use kerberized cliens without any changes at all.

    Now, if you want *password* authentication, as opposed to ticket-based,
    that's another story -- e.g., if you want sshd to verify a password
    supplied by the password or keyboard-interactive userauth methods. Then
    the host needs a shared key with the KDC so that it can verify the KDC's
    identity and prevent a spoofing attack. I think pam_krb5 lets you turn
    off that verification, but it's unwise from a security standpoint.

    - Richard

    BK> Right now, when I ssh in, it hangs and I get this with debug
    BK> turned on:

    BK> Jan 16 09:48:17 bkingkstest1 sshd[2295]: pam_krb5[2295]: trying
    BK> previously-entered password for 'bking', allowing libkrb5 to
    BK> prompt for more Jan 16 09:48:17 bkingkstest1 sshd[2295]:
    BK> pam_krb5[2295]: authenticating ' bking@REALM' to
    BK> 'krbtgt/REALM@REALM' Jan 16 09:48:17 bkingkstest1 sshd[2295]:
    BK> pam_krb5[2295]: krb5_get_init_creds_password(krbtgt/REALM@REALM
    BK> returned 0 (Success) Jan 16 09:48:17 bkingkstest1 sshd[2295]:
    BK> pam_krb5[2295]: got result 0 (Success)

    BK> Thoughts?

    BK> My (sanitized) krb5.conf:

    BK> [logging] default = SYSLOG:ERR:USER

    BK> [libdefaults] default_realm = REALM dns_lookup_kdc = false
    BK> dns_lookup_realm = false noaddresses = true validate = false

    BK> [realms] EXPERTCITY.COM = { kdc = names1.realm master_kdc =
    BK> names0.realm admin_server = names0.realm auth_to_local =
    BK> RULE:[2:$1;$2](.*;root)s/;root$// auth_to_local =
    BK> RULE:[2:$1;$2](.*;admin)s/;admin$//

    BK> auth_to_local = DEFAULT
    BK> }

    [domain_realm]
    BK> .realm = REALM

    BK> [appdefaults] pam = { forwardable = true
    BK> }

    My pam.d/system-auth:

    BK> auth required /lib/security/$ISA/pam_env.so auth sufficient
    BK> /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient
    BK> /lib/security/$ISA/pam_krb5.so minimum_uid=3000 use_authtok debug
    BK> #auth required /lib/security/$ISA/pam_deny.so

    BK> account required /lib/security/$ISA/pam_unix.so broken_shadow
    BK> account sufficient /lib/security/$ISA/pam_localuser.so account
    BK> sufficient /lib/security/$ISA/pam_krb5.so debug account sufficient
    BK> /lib/security/$ISA/pam_ldap.so debug account required
    BK> /lib/security/$ISA/pam_permit.so

    BK> password requisite /lib/security/$ISA/pam_cracklib.so retry=3
    BK> password sufficient /lib/security/$ISA/pam_unix.so nullok
    BK> use_authtok md5 shadow password sufficient
    BK> /lib/security/$ISA/pam_krb5.so use_authtok debug password required
    BK> /lib/security/$ISA/pam_deny.so debug

    BK> session required /lib/security/$ISA/pam_limits.so session required
    BK> /lib/security/$ISA/pam_unix.so #session required
    BK> /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel/ umask=0022
    BK> sauth required /lib/security/$ISA/pam_env.so auth sufficient
    BK> /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient
    BK> /lib/security/$ISA/pam_krb5.so minimum_uid=3000 use_authtok debug
    BK> #auth required /lib/security/$ISA/pam_deny.so

    BK> account required /lib/security/$ISA/pam_unix.so broken_shadow
    BK> account sufficient /lib/security/$ISA/pam_localuser.so account
    BK> sufficient /lib/security/$ISA/pam_krb5.so debug account sufficient
    BK> /lib/security/$ISA/pam_ldap.so debug account required
    BK> /lib/security/$ISA/pam_permit.so

    BK> password requisite /lib/security/$ISA/pam_cracklib.so retry=3
    BK> password sufficient /lib/security/$ISA/pam_unix.so nullok
    BK> use_authtok md5 shadow password sufficient
    BK> /lib/security/$ISA/pam_krb5.so use_authtok debug password required
    BK> /lib/security/$ISA/pam_deny.so debug

    BK> session required /lib/security/$ISA/pam_limits.so session required
    BK> /lib/security/$ISA/pam_unix.so #session required
    BK> /lib/security/$ISA/pam_mkhomedir.so skel=/etc/skel/ umask=0022
    BK> session optional /lib/security/$ISA/pam_krb5.so debug session
    BK> optional /lib/security/$ISA/pam_ldap.so debug session optional
    BK> /lib/security/$ISA/pam_krb5.so debug session optional
    BK> /lib/security/$ISA/pam_ldap.so debug

    BK> Any ideas? Is what I'm trying even possible?

    BK> Thanks,

    BK> -- Barry King barryking93@gmail.com

    --
    Richard Silverman
    res@qoxp.net


+ Reply to Thread