Password incorrect while getting initial credentials using keytab onSolaris with AD - Kerberos

This is a discussion on Password incorrect while getting initial credentials using keytab onSolaris with AD - Kerberos ; Hi, I am stumped as to what is wrong with my Kerberos authentication. What I am trying to do is get Kerberos working so I can then use mod_auth_kerb with Apache to authenticate our domain users. I have compiled and ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Password incorrect while getting initial credentials using keytab onSolaris with AD

  1. Password incorrect while getting initial credentials using keytab onSolaris with AD

    Hi,

    I am stumped as to what is wrong with my Kerberos authentication.
    What I am trying to do is get Kerberos working so I can then use
    mod_auth_kerb with Apache to authenticate our domain users.

    I have compiled and installed MIT Kerberos 1.5.4, on Solaris 9, and
    configured my /etc/krb5.conf as follows:
    [libdefaults]
    default_realm = CORP.FC.LOCAL
    default_tkt_enctypes = des-cbc-md5 des-cbc-crc
    default_tgs_enctypes = des-cbc-md5 des-cbc-crc

    [domain_realm]
    .fc.fujitsu.com = CORP.FC.LOCAL

    [realms]
    CORP.FC.LOCAL = {
    admin_server = dc.corp.fc.local:464
    kdc = dc.corp.fc.local:88
    kpasswd_server = dc.corp.fc.local:464
    }

    [logging]
    kdc = FILE:/var/log/kerberos/krb5kdc.log
    admin_server = FILE:/var/log/kerberos/kadmin.log
    default = FILE:/var/log/kerberos/krb5lib.log

    I tested with the kinit command and I am able to get a Kerberos ticket
    with my own domain ID and password:
    root@fc650dr:/usr/www/kerberos/bin # kinit seelypet
    Password for seelypet@CORP.FC.LOCAL:
    root@fc650dr:/usr/www/kerberos/bin # klist -e
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: seelypet@CORP.FC.LOCAL

    Valid starting Expires Service principal
    03/25/08 11:12:26 03/25/08 21:12:31 krbtgt/
    CORP.FC.LOCAL@CORP.FC.LOCAL
    renew until 03/26/08 11:12:26, Etype (skey, tkt): DES cbc mode
    with RSA-MD5, ArcFour with HMAC/md5

    We have created a user to be used for the Apache Kerberos
    authentication in Active Directory (Windows 2003 SP1) with the
    following properties:
    - User cannot change password
    - Password never expires
    - Use DES encryption types with this account
    - Does not require Kerberos preauthentication

    I am able to get a Kerberos ticket with this account when I supply the
    password:

    root@fc650dr:/usr/www/kerberos/bin # kinit Apache-DBA.Account
    Password for Apache-DBA.Account@CORP.FC.LOCAL:
    root@fc650dr:/usr/www/kerberos/bin # klist -e
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: Apache-DBA.Account@CORP.FC.LOCAL

    Valid starting Expires Service principal
    03/25/08 11:14:31 03/25/08 21:14:31 krbtgt/
    CORP.FC.LOCAL@CORP.FC.LOCAL
    renew until 03/26/08 11:14:31, Etype (skey, tkt): DES cbc mode
    with RSA-MD5, ArcFour with HMAC/md5

    We generated a keytab file on the Active Directory DC for this
    account, to map to service principal HTTP/fc650dr.fc.fujitsu.com,
    with the following command
    ktpass -princ HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL -mapuser CORP
    \Apache-DBA.Account -crypto DES-CBC-MD5 -ptype KRB5_NT_SRV_HST -pass
    passw0rd -out c:\ktpass\fc650drkeytabv4

    I verified that, in Active Directory, the "User login name" shows HTTP/
    fc650dr.fc.fujitsu.com, indicating that the mapping was made.

    The keytab file was transferred to the Solaris server. When I try to
    use the keytab file, this is the result:
    root@fc650dr:/usr/www/kerberos/bin # kinit -kt fc650drkeytabv4 HTTP/
    fc650dr.fc.fujitsu.com
    kinit(v5): Password incorrect while getting initial credentials

    However I am able to get a Kerberos ticket using the SPN shown, when I
    supply the password:
    root@fc650dr:/usr/www/kerberos/bin # kinit HTTP/fc650dr.fc.fujitsu.com
    Password for HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL:
    root@fc650dr:/usr/www/kerberos/bin # klist -e
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL

    Valid starting Expires Service principal
    03/25/08 11:21:30 03/25/08 21:21:30 krbtgt/
    CORP.FC.LOCAL@CORP.FC.LOCAL
    renew until 03/26/08 11:21:30, Etype (skey, tkt): DES cbc mode
    with RSA-MD5, ArcFour with HMAC/md5

    The kvno in the keytab looks like it matches the ticket being given by
    AD:
    root@fc650dr:/usr/www/kerberos/bin # klist -kt fc650drkeytabv4
    Keytab name: FILE:fc650drkeytabv4
    KVNO Timestamp Principal
    ---- -----------------
    --------------------------------------------------------
    2 12/31/69 20:00:00 HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL

    root@fc650dr:/usr/www/kerberos/bin # kvno HTTP/fc650dr.fc.fujitsu.com
    HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL: kvno = 2

    I tried creating a keytab on the Solaris machine using ktutil with
    this command:
    addent -password -p HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL -k 2 -e
    des-cbc-md5

    but the result is the same as above when testing with this keytab
    also.

    Any idea what can be wrong here? Any ideas much appreciated.

    Thanks.




  2. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    Your problem might be a bad version of ktpass.
    See http://support.microsoft.com/kb/919557

    "You receive pre-authentication errors when you use
    keytab files that are generated by using the Ktpass.exe
    tool on a Windows Server 2003 SP1-based computer"


    PS wrote:
    > Hi,
    >
    > I am stumped as to what is wrong with my Kerberos authentication.
    > What I am trying to do is get Kerberos working so I can then use
    > mod_auth_kerb with Apache to authenticate our domain users.
    >
    > I have compiled and installed MIT Kerberos 1.5.4, on Solaris 9, and
    > configured my /etc/krb5.conf as follows:
    > [libdefaults]
    > default_realm = CORP.FC.LOCAL
    > default_tkt_enctypes = des-cbc-md5 des-cbc-crc
    > default_tgs_enctypes = des-cbc-md5 des-cbc-crc
    >
    > [domain_realm]
    > .fc.fujitsu.com = CORP.FC.LOCAL
    >
    > [realms]
    > CORP.FC.LOCAL = {
    > admin_server = dc.corp.fc.local:464
    > kdc = dc.corp.fc.local:88
    > kpasswd_server = dc.corp.fc.local:464
    > }
    >
    > [logging]
    > kdc = FILE:/var/log/kerberos/krb5kdc.log
    > admin_server = FILE:/var/log/kerberos/kadmin.log
    > default = FILE:/var/log/kerberos/krb5lib.log
    >
    > I tested with the kinit command and I am able to get a Kerberos ticket
    > with my own domain ID and password:
    > root@fc650dr:/usr/www/kerberos/bin # kinit seelypet
    > Password for seelypet@CORP.FC.LOCAL:
    > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > Ticket cache: FILE:/tmp/krb5cc_0
    > Default principal: seelypet@CORP.FC.LOCAL
    >
    > Valid starting Expires Service principal
    > 03/25/08 11:12:26 03/25/08 21:12:31 krbtgt/
    > CORP.FC.LOCAL@CORP.FC.LOCAL
    > renew until 03/26/08 11:12:26, Etype (skey, tkt): DES cbc mode
    > with RSA-MD5, ArcFour with HMAC/md5
    >
    > We have created a user to be used for the Apache Kerberos
    > authentication in Active Directory (Windows 2003 SP1) with the
    > following properties:
    > - User cannot change password
    > - Password never expires
    > - Use DES encryption types with this account
    > - Does not require Kerberos preauthentication
    >
    > I am able to get a Kerberos ticket with this account when I supply the
    > password:
    >
    > root@fc650dr:/usr/www/kerberos/bin # kinit Apache-DBA.Account
    > Password for Apache-DBA.Account@CORP.FC.LOCAL:
    > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > Ticket cache: FILE:/tmp/krb5cc_0
    > Default principal: Apache-DBA.Account@CORP.FC.LOCAL
    >
    > Valid starting Expires Service principal
    > 03/25/08 11:14:31 03/25/08 21:14:31 krbtgt/
    > CORP.FC.LOCAL@CORP.FC.LOCAL
    > renew until 03/26/08 11:14:31, Etype (skey, tkt): DES cbc mode
    > with RSA-MD5, ArcFour with HMAC/md5
    >
    > We generated a keytab file on the Active Directory DC for this
    > account, to map to service principal HTTP/fc650dr.fc.fujitsu.com,
    > with the following command
    > ktpass -princ HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL -mapuser CORP
    > \Apache-DBA.Account -crypto DES-CBC-MD5 -ptype KRB5_NT_SRV_HST -pass
    > passw0rd -out c:\ktpass\fc650drkeytabv4
    >
    > I verified that, in Active Directory, the "User login name" shows HTTP/
    > fc650dr.fc.fujitsu.com, indicating that the mapping was made.
    >
    > The keytab file was transferred to the Solaris server. When I try to
    > use the keytab file, this is the result:
    > root@fc650dr:/usr/www/kerberos/bin # kinit -kt fc650drkeytabv4 HTTP/
    > fc650dr.fc.fujitsu.com
    > kinit(v5): Password incorrect while getting initial credentials
    >
    > However I am able to get a Kerberos ticket using the SPN shown, when I
    > supply the password:
    > root@fc650dr:/usr/www/kerberos/bin # kinit HTTP/fc650dr.fc.fujitsu.com
    > Password for HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL:
    > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > Ticket cache: FILE:/tmp/krb5cc_0
    > Default principal: HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL
    >
    > Valid starting Expires Service principal
    > 03/25/08 11:21:30 03/25/08 21:21:30 krbtgt/
    > CORP.FC.LOCAL@CORP.FC.LOCAL
    > renew until 03/26/08 11:21:30, Etype (skey, tkt): DES cbc mode
    > with RSA-MD5, ArcFour with HMAC/md5
    >
    > The kvno in the keytab looks like it matches the ticket being given by
    > AD:
    > root@fc650dr:/usr/www/kerberos/bin # klist -kt fc650drkeytabv4
    > Keytab name: FILE:fc650drkeytabv4
    > KVNO Timestamp Principal
    > ---- -----------------
    > --------------------------------------------------------
    > 2 12/31/69 20:00:00 HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL
    >
    > root@fc650dr:/usr/www/kerberos/bin # kvno HTTP/fc650dr.fc.fujitsu.com
    > HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL: kvno = 2
    >
    > I tried creating a keytab on the Solaris machine using ktutil with
    > this command:
    > addent -password -p HTTP/fc650dr.fc.fujitsu.com@CORP.FC.LOCAL -k 2 -e
    > des-cbc-md5
    >
    > but the result is the same as above when testing with this keytab
    > also.
    >
    > Any idea what can be wrong here? Any ideas much appreciated.
    >
    > Thanks.
    >
    >
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  3. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    > Your problem might be a bad version of ktpass.
    > Seehttp://support.microsoft.com/kb/919557
    >
    > "You receive pre-authentication errors when you use
    > keytab files that are generated by using the Ktpass.exe
    > tool on a Windows Server 2003 SP1-based computer"
    >
    >
    >
    > PS wrote:
    > > Hi,

    >
    > > I am stumped as to what is wrong with my Kerberos authentication.
    > > What I am trying to do is get Kerberos working so I can then use
    > > mod_auth_kerb with Apache to authenticate our domain users.

    >
    > > I have compiled and installed MIT Kerberos 1.5.4, on Solaris 9, and
    > > configured my /etc/krb5.conf as follows:
    > > [libdefaults]
    > > default_realm = CORP.FC.LOCAL
    > > default_tkt_enctypes = des-cbc-md5 des-cbc-crc
    > > default_tgs_enctypes = des-cbc-md5 des-cbc-crc

    >
    > > [domain_realm]
    > > .fc.fujitsu.com = CORP.FC.LOCAL

    >
    > > [realms]
    > > CORP.FC.LOCAL = {
    > > admin_server = dc.corp.fc.local:464
    > > kdc = dc.corp.fc.local:88
    > > kpasswd_server = dc.corp.fc.local:464
    > > }

    >
    > > [logging]
    > > kdc = FILE:/var/log/kerberos/krb5kdc.log
    > > admin_server = FILE:/var/log/kerberos/kadmin.log
    > > default = FILE:/var/log/kerberos/krb5lib.log

    >
    > > I tested with the kinit command and I am able to get a Kerberos ticket
    > > with my own domain ID and password:
    > > root@fc650dr:/usr/www/kerberos/bin # kinit seelypet
    > > Password for seely...@CORP.FC.LOCAL:
    > > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > > Ticket cache: FILE:/tmp/krb5cc_0
    > > Default principal: seely...@CORP.FC.LOCAL

    >
    > > Valid starting Expires Service principal
    > > 03/25/08 11:12:26 03/25/08 21:12:31 krbtgt/
    > > CORP.FC.LO...@CORP.FC.LOCAL
    > > renew until 03/26/08 11:12:26, Etype (skey, tkt): DES cbc mode
    > > with RSA-MD5, ArcFour with HMAC/md5

    >
    > > We have created a user to be used for the Apache Kerberos
    > > authentication in Active Directory (Windows 2003 SP1) with the
    > > following properties:
    > > - User cannot change password
    > > - Password never expires
    > > - Use DES encryption types with this account
    > > - Does not require Kerberos preauthentication

    >
    > > I am able to get a Kerberos ticket with this account when I supply the
    > > password:

    >
    > > root@fc650dr:/usr/www/kerberos/bin # kinit Apache-DBA.Account
    > > Password for Apache-DBA.Acco...@CORP.FC.LOCAL:
    > > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > > Ticket cache: FILE:/tmp/krb5cc_0
    > > Default principal: Apache-DBA.Acco...@CORP.FC.LOCAL

    >
    > > Valid starting Expires Service principal
    > > 03/25/08 11:14:31 03/25/08 21:14:31 krbtgt/
    > > CORP.FC.LO...@CORP.FC.LOCAL
    > > renew until 03/26/08 11:14:31, Etype (skey, tkt): DES cbc mode
    > > with RSA-MD5, ArcFour with HMAC/md5

    >
    > > We generated a keytab file on the Active Directory DC for this
    > > account, to map to service principal HTTP/fc650dr.fc.fujitsu.com,
    > > with the following command
    > > ktpass -princ HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL -mapuser CORP
    > > \Apache-DBA.Account -crypto DES-CBC-MD5 -ptype KRB5_NT_SRV_HST -pass
    > > passw0rd -out c:\ktpass\fc650drkeytabv4

    >
    > > I verified that, in Active Directory, the "User login name" shows HTTP/
    > > fc650dr.fc.fujitsu.com, indicating that the mapping was made.

    >
    > > The keytab file was transferred to the Solaris server. When I try to
    > > use the keytab file, this is the result:
    > > root@fc650dr:/usr/www/kerberos/bin # kinit -kt fc650drkeytabv4 HTTP/
    > > fc650dr.fc.fujitsu.com
    > > kinit(v5): Password incorrect while getting initial credentials

    >
    > > However I am able to get a Kerberos ticket using the SPN shown, when I
    > > supply the password:
    > > root@fc650dr:/usr/www/kerberos/bin # kinit HTTP/fc650dr.fc.fujitsu.com
    > > Password for HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL:
    > > root@fc650dr:/usr/www/kerberos/bin # klist -e
    > > Ticket cache: FILE:/tmp/krb5cc_0
    > > Default principal: HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL

    >
    > > Valid starting Expires Service principal
    > > 03/25/08 11:21:30 03/25/08 21:21:30 krbtgt/
    > > CORP.FC.LO...@CORP.FC.LOCAL
    > > renew until 03/26/08 11:21:30, Etype (skey, tkt): DES cbc mode
    > > with RSA-MD5, ArcFour with HMAC/md5

    >
    > > The kvno in the keytab looks like it matches the ticket being given by
    > > AD:
    > > root@fc650dr:/usr/www/kerberos/bin # klist -kt fc650drkeytabv4
    > > Keytab name: FILE:fc650drkeytabv4
    > > KVNO Timestamp Principal
    > > ---- -----------------
    > > --------------------------------------------------------
    > > 2 12/31/69 20:00:00 HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL

    >
    > > root@fc650dr:/usr/www/kerberos/bin # kvno HTTP/fc650dr.fc.fujitsu.com
    > > HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL: kvno = 2

    >
    > > I tried creating a keytab on the Solaris machine using ktutil with
    > > this command:
    > > addent -password -p HTTP/fc650dr.fc.fujitsu....@CORP.FC.LOCAL -k 2 -e
    > > des-cbc-md5

    >
    > > but the result is the same as above when testing with this keytab
    > > also.

    >
    > > Any idea what can be wrong here? Any ideas much appreciated.

    >
    > > Thanks.

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

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444


    That could be the case.

    But what about the fact mentioned that I created a keytab using ktutil
    addent as shown on the Solaris box, supplying the password, and I
    still get the same result? But when I kinit with this same password I
    get the ticket?

  4. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD



    PS wrote:
    > On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    >> Your problem might be a bad version of ktpass.
    >> Seehttp://support.microsoft.com/kb/919557

    >
    > That could be the case.
    >
    > But what about the fact mentioned that I created a keytab using ktutil
    > addent as shown on the Solaris box, supplying the password, and I
    > still get the same result?


    The key is a function of the password and the salt. With DES the
    password is concatenated with the salt which is usually the concatenation
    of the realm and components of the principal name.

    Since an AD account has only one password, but can have a UPN and SPNs,
    the salt is based on the samAccountName.

    So when you used the ktutil, it assumed a salt based on the principal.

    > But when I kinit with this same password I > get the ticket?


    Part of the pre-auth protocol is for the KDC to send the salt
    to the kinit client. Kinit then combines the password and the KDC's
    salt to generate the key.

    If you want to see the KDC's salt, you can use a network trace
    program like wireshark.

    If you are going to have a lot of unix services or hosts, you might want to
    google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    update keytab files.


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


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  5. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    On Mar 25, 12:33 pm, "Douglas E. Engert" wrote:
    > PS wrote:
    > > On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    > >> Your problem might be a bad version of ktpass.
    > >> Seehttp://support.microsoft.com/kb/919557

    >
    > > That could be the case.

    >
    > > But what about the fact mentioned that I created a keytab using ktutil
    > > addent as shown on the Solaris box, supplying the password, and I
    > > still get the same result?

    >
    > The key is a function of the password and the salt. With DES the
    > password is concatenated with the salt which is usually the concatenation
    > of the realm and components of the principal name.
    >
    > Since an AD account has only one password, but can have a UPN and SPNs,
    > the salt is based on the samAccountName.
    >
    > So when you used the ktutil, it assumed a salt based on the principal.
    >
    > > But when I kinit with this same password I > get the ticket?

    >
    > Part of the pre-auth protocol is for the KDC to send the salt
    > to the kinit client. Kinit then combines the password and the KDC's
    > salt to generate the key.
    >
    > If you want to see the KDC's salt, you can use a network trace
    > program like wireshark.
    >
    > If you are going to have a lot of unix services or hosts, you might want to
    > google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    > update keytab files.
    >
    > > ________________________________________________
    > > Kerberos mailing list Kerbe...@mit.edu
    > >https://mailman.mit.edu/mailman/listinfo/kerberos

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444


    Hi,

    I had to download and build Cyrus SASL, and consequently rebuild
    OpenLDAP, but I have a working msktutil (it seems).

    I tried to use the command as follows, with the result. Any ideas if
    I am doing something wrong here?

    msktutil --verbose --create --hostname fc650dr.fc.fujitsu.com --
    server dc.corp.fc.local
    -- get_default_keytab: Obtaining the default keytab name: /etc/
    krb5.keytab
    -- get_default_ou: Determining default OU: CN=Computers
    -- init_password: Wiping the computer password structure
    -- finalize_exec: Determining user principal name
    -- finalize_exec: User Principal Name is: host/
    fc650dr.fc.fujitsu.com@CORP.FC.LOCAL
    -- create_fake_krb5_conf: Created a fake krb5.conf file: /
    tmp/.mskt-9661krb5.conf
    -- get_krb5_context: Creating Kerberos Context
    -- try_machine_keytab: Using the local credential cache: /
    tmp/.mskt-9661krb5_ccache
    -- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
    found in Kerberos database)
    -- try_machine_keytab: Unable to authenticate using the local keytab
    -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    SASL/EXTERNAL authentication started
    Error: ldap_set_option failed (Unknown authentication method)
    Error: ldap_connect failed
    -- krb5_cleanup: Destroying Kerberos Context
    -- ldap_cleanup: Disconnecting from LDAP server
    -- init_password: Wiping the computer password structure

  6. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD



    PS wrote:
    > On Mar 25, 12:33 pm, "Douglas E. Engert" wrote:
    >> PS wrote:
    >>> On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    >>>> Your problem might be a bad version of ktpass.
    >>>> Seehttp://support.microsoft.com/kb/919557
    >>> That could be the case.
    >>> But what about the fact mentioned that I created a keytab using ktutil
    >>> addent as shown on the Solaris box, supplying the password, and I
    >>> still get the same result?

    >> The key is a function of the password and the salt. With DES the
    >> password is concatenated with the salt which is usually the concatenation
    >> of the realm and components of the principal name.
    >>
    >> Since an AD account has only one password, but can have a UPN and SPNs,
    >> the salt is based on the samAccountName.
    >>
    >> So when you used the ktutil, it assumed a salt based on the principal.
    >>
    >>> But when I kinit with this same password I > get the ticket?

    >> Part of the pre-auth protocol is for the KDC to send the salt
    >> to the kinit client. Kinit then combines the password and the KDC's
    >> salt to generate the key.
    >>
    >> If you want to see the KDC's salt, you can use a network trace
    >> program like wireshark.
    >>
    >> If you are going to have a lot of unix services or hosts, you might want to
    >> google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    >> update keytab files.
    >>
    >>> ________________________________________________
    >>> Kerberos mailing list Kerbe...@mit.edu
    >>> https://mailman.mit.edu/mailman/listinfo/kerberos

    >> --
    >>
    >> Douglas E. Engert
    >> Argonne National Laboratory
    >> 9700 South Cass Avenue
    >> Argonne, Illinois 60439
    >> (630) 252-5444

    >
    > Hi,
    >
    > I had to download and build Cyrus SASL, and consequently rebuild
    > OpenLDAP, but I have a working msktutil (it seems).
    >
    > I tried to use the command as follows, with the result. Any ideas if
    > I am doing something wrong here?
    >


    msktutil expects to be run as root (or user who owned the keytab)
    with Kerberos credentials previous of an AD administrator who can write into
    the branch of the tree where the account is located.
    (Or if renewing the keytab, it can use the credentials in the keytab.)

    Tthe options we use are
    -b base
    -k kettab
    -h hostname
    -s service. i.e. host, HTTP, ldap, afs ... the service part of the principal
    --upn upn
    --computer-name unique-short-name as this must fit in 19 character
    as it plus a "$" becomes the samAccountName. we uses a convention of
    --


    > msktutil --verbose --create --hostname fc650dr.fc.fujitsu.com --
    > server dc.corp.fc.local
    > -- get_default_keytab: Obtaining the default keytab name: /etc/
    > krb5.keytab
    > -- get_default_ou: Determining default OU: CN=Computers
    > -- init_password: Wiping the computer password structure
    > -- finalize_exec: Determining user principal name
    > -- finalize_exec: User Principal Name is: host/
    > fc650dr.fc.fujitsu.com@CORP.FC.LOCAL


    Since you did not specify -s, "host" was used.

    > -- create_fake_krb5_conf: Created a fake krb5.conf file: /
    > tmp/.mskt-9661krb5.conf
    > -- get_krb5_context: Creating Kerberos Context
    > -- try_machine_keytab: Using the local credential cache: /
    > tmp/.mskt-9661krb5_ccache
    > -- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
    > found in Kerberos database)
    > -- try_machine_keytab: Unable to authenticate using the local keytab


    Its trying to use the previous keytab to authenticate to AD which
    does not exist yet. SO this is normal.

    > -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > SASL/EXTERNAL authentication started


    It should be using SASL/GSSAPI, did you build SASL with Kerberos?
    It should say next:
    SASL/GSSAPI authentication started
    SASL username: youradmin@YOUR.REALM
    Where the AD admin is called youradmin@YOUR.REALM



    > Error: ldap_set_option failed (Unknown authentication method)
    > Error: ldap_connect failed
    > -- krb5_cleanup: Destroying Kerberos Context
    > -- ldap_cleanup: Disconnecting from LDAP server
    > -- init_password: Wiping the computer password structure
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  7. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    On Mar 25, 5:19 pm, "Douglas E. Engert" wrote:
    > PS wrote:
    > > On Mar 25, 12:33 pm, "Douglas E. Engert" wrote:
    > >> PS wrote:
    > >>> On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    > >>>> Your problem might be a bad version of ktpass.
    > >>>> Seehttp://support.microsoft.com/kb/919557
    > >>> That could be the case.
    > >>> But what about the fact mentioned that I created a keytab using ktutil
    > >>> addent as shown on the Solaris box, supplying the password, and I
    > >>> still get the same result?
    > >> The key is a function of the password and the salt. With DES the
    > >> password is concatenated with the salt which is usually the concatenation
    > >> of the realm and components of the principal name.

    >
    > >> Since an AD account has only one password, but can have a UPN and SPNs,
    > >> the salt is based on the samAccountName.

    >
    > >> So when you used the ktutil, it assumed a salt based on the principal.

    >
    > >>> But when I kinit with this same password I > get the ticket?
    > >> Part of the pre-auth protocol is for the KDC to send the salt
    > >> to the kinit client. Kinit then combines the password and the KDC's
    > >> salt to generate the key.

    >
    > >> If you want to see the KDC's salt, you can use a network trace
    > >> program like wireshark.

    >
    > >> If you are going to have a lot of unix services or hosts, you might want to
    > >> google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    > >> update keytab files.

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

    >
    > >> Douglas E. Engert
    > >> Argonne National Laboratory
    > >> 9700 South Cass Avenue
    > >> Argonne, Illinois 60439
    > >> (630) 252-5444

    >
    > > Hi,

    >
    > > I had to download and build Cyrus SASL, and consequently rebuild
    > > OpenLDAP, but I have a working msktutil (it seems).

    >
    > > I tried to use the command as follows, with the result. Any ideas if
    > > I am doing something wrong here?

    >
    > msktutil expects to be run as root (or user who owned the keytab)
    > with Kerberos credentials previous of an AD administrator who can write into
    > the branch of the tree where the account is located.
    > (Or if renewing the keytab, it can use the credentials in the keytab.)
    >
    > Tthe options we use are
    > -b base
    > -k kettab
    > -h hostname
    > -s service. i.e. host, HTTP, ldap, afs ... the service part of the principal
    > --upn upn
    > --computer-name unique-short-name as this must fit in 19 character
    > as it plus a "$" becomes the samAccountName. we uses a convention of
    > --
    >
    > > msktutil --verbose --create --hostname fc650dr.fc.fujitsu.com --
    > > server dc.corp.fc.local
    > > -- get_default_keytab: Obtaining the default keytab name: /etc/
    > > krb5.keytab
    > > -- get_default_ou: Determining default OU: CN=Computers
    > > -- init_password: Wiping the computer password structure
    > > -- finalize_exec: Determining user principal name
    > > -- finalize_exec: User Principal Name is: host/
    > > fc650dr.fc.fujitsu....@CORP.FC.LOCAL

    >
    > Since you did not specify -s, "host" was used.
    >
    > > -- create_fake_krb5_conf: Created a fake krb5.conf file: /
    > > tmp/.mskt-9661krb5.conf
    > > -- get_krb5_context: Creating Kerberos Context
    > > -- try_machine_keytab: Using the local credential cache: /
    > > tmp/.mskt-9661krb5_ccache
    > > -- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
    > > found in Kerberos database)
    > > -- try_machine_keytab: Unable to authenticate using the local keytab

    >
    > Its trying to use the previous keytab to authenticate to AD which
    > does not exist yet. SO this is normal.
    >
    > > -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > > -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > > SASL/EXTERNAL authentication started

    >
    > It should be using SASL/GSSAPI, did you build SASL with Kerberos?
    > It should say next:
    > SASL/GSSAPI authentication started
    > SASL username: yourad...@YOUR.REALM
    > Where the AD admin is called yourad...@YOUR.REALM
    >
    > > Error: ldap_set_option failed (Unknown authentication method)
    > > Error: ldap_connect failed
    > > -- krb5_cleanup: Destroying Kerberos Context
    > > -- ldap_cleanup: Disconnecting from LDAP server
    > > -- init_password: Wiping the computer password structure
    > > ________________________________________________
    > > Kerberos mailing list Kerbe...@mit.edu
    > >https://mailman.mit.edu/mailman/listinfo/kerberos

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444


    Hi,

    This was the build I did, and in this order, with these options:
    Kerberos 1.5.4:
    ../configure --prefix=/usr/www/kerberos --without-krb4 --without-tcl --
    disable-thread-support --enable-shared --disable-static

    OpenLDAP 2.4.8:
    CC=gcc ./configure --prefix=/usr/www/libs/ldap --without-cyrus-sasl --
    disable-slapd --disable-slurpd --with-tls=openssl --enable-shared --
    disable-static

    Cyrus SASL 2.2.21:
    ../configure --prefix=/usr/www/libs/sasl --with-openssl=/usr/www/libs/
    ssl --with-dblib=none --enable-gssapi=/usr/www/kerberos --with-
    gss_impl=mit -with-ldap=/usr/www/libs/ldap --enable-shared --disable-
    static

    OpenLDAP 2.4.8 (again... cyclical dependency with SASL...):
    CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    usr/www/libs/sasl/include'
    CC=gcc ./configure --prefix=$BLIB/ldap --with-cyrus-sasl --disable-
    slapd --disable-slurpd --with-tls=openssl --enable-shared --disable-
    static

    msktutil:
    CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    usr/www/libs/sasl/include -I /usr/www/kerberos/include'
    ../configure --prefix=/usr/www/msktutil --with-tmpdir=/tmp --with-krb5=/
    usr/www/kerberos --with-ldapdir=/usr/www/libs/ldap --with-sasldir=/usr/
    www/libs/sasl --enable-shared --disable-statuc
    Edit config.h - Add the lines to the top because configure failed
    to detect this properly:
    #define HAVE_GETHOSTBYADDR 1
    #define HAVE_GETHOSTBYNAME 1
    Edit Makefile - Change LIBS to be: LIBS=-lsocket -lnsl -lkrb5 -
    lldap -lk5crypto -lsasl2 -lcom_err


  8. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    Share libs doing dynamic loads have always been a problem when not
    built in /usr/local. You might need:

    SASL_PATH=usr/www/libs/sasl/sasl2 (Or whereever sasl2 is)
    export SASL_PATH
    LD_LIBRARY_PATH=/usr/www/kerberos/lib
    export LD_LIBRARY_PATH


    PS wrote:
    > On Mar 25, 5:19 pm, "Douglas E. Engert" wrote:
    >> PS wrote:
    >>> On Mar 25, 12:33 pm, "Douglas E. Engert" wrote:
    >>>> PS wrote:
    >>>>> On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    >>>>>> Your problem might be a bad version of ktpass.
    >>>>>> Seehttp://support.microsoft.com/kb/919557
    >>>>> That could be the case.
    >>>>> But what about the fact mentioned that I created a keytab using ktutil
    >>>>> addent as shown on the Solaris box, supplying the password, and I
    >>>>> still get the same result?
    >>>> The key is a function of the password and the salt. With DES the
    >>>> password is concatenated with the salt which is usually the concatenation
    >>>> of the realm and components of the principal name.
    >>>> Since an AD account has only one password, but can have a UPN and SPNs,
    >>>> the salt is based on the samAccountName.
    >>>> So when you used the ktutil, it assumed a salt based on the principal.
    >>>>> But when I kinit with this same password I > get the ticket?
    >>>> Part of the pre-auth protocol is for the KDC to send the salt
    >>>> to the kinit client. Kinit then combines the password and the KDC's
    >>>> salt to generate the key.
    >>>> If you want to see the KDC's salt, you can use a network trace
    >>>> program like wireshark.
    >>>> If you are going to have a lot of unix services or hosts, you might want to
    >>>> google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    >>>> update keytab files.
    >>>>> ________________________________________________
    >>>>> Kerberos mailing list Kerbe...@mit.edu
    >>>>> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>>> --
    >>>> Douglas E. Engert
    >>>> Argonne National Laboratory
    >>>> 9700 South Cass Avenue
    >>>> Argonne, Illinois 60439
    >>>> (630) 252-5444
    >>> Hi,
    >>> I had to download and build Cyrus SASL, and consequently rebuild
    >>> OpenLDAP, but I have a working msktutil (it seems).
    >>> I tried to use the command as follows, with the result. Any ideas if
    >>> I am doing something wrong here?

    >> msktutil expects to be run as root (or user who owned the keytab)
    >> with Kerberos credentials previous of an AD administrator who can write into
    >> the branch of the tree where the account is located.
    >> (Or if renewing the keytab, it can use the credentials in the keytab.)
    >>
    >> Tthe options we use are
    >> -b base
    >> -k kettab
    >> -h hostname
    >> -s service. i.e. host, HTTP, ldap, afs ... the service part of the principal
    >> --upn upn
    >> --computer-name unique-short-name as this must fit in 19 character
    >> as it plus a "$" becomes the samAccountName. we uses a convention of
    >> --
    >>
    >>> msktutil --verbose --create --hostname fc650dr.fc.fujitsu.com --
    >>> server dc.corp.fc.local
    >>> -- get_default_keytab: Obtaining the default keytab name: /etc/
    >>> krb5.keytab
    >>> -- get_default_ou: Determining default OU: CN=Computers
    >>> -- init_password: Wiping the computer password structure
    >>> -- finalize_exec: Determining user principal name
    >>> -- finalize_exec: User Principal Name is: host/
    >>> fc650dr.fc.fujitsu....@CORP.FC.LOCAL

    >> Since you did not specify -s, "host" was used.
    >>
    >>> -- create_fake_krb5_conf: Created a fake krb5.conf file: /
    >>> tmp/.mskt-9661krb5.conf
    >>> -- get_krb5_context: Creating Kerberos Context
    >>> -- try_machine_keytab: Using the local credential cache: /
    >>> tmp/.mskt-9661krb5_ccache
    >>> -- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
    >>> found in Kerberos database)
    >>> -- try_machine_keytab: Unable to authenticate using the local keytab

    >> Its trying to use the previous keytab to authenticate to AD which
    >> does not exist yet. SO this is normal.
    >>
    >>> -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    >>> -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    >>> SASL/EXTERNAL authentication started

    >> It should be using SASL/GSSAPI, did you build SASL with Kerberos?
    >> It should say next:
    >> SASL/GSSAPI authentication started
    >> SASL username: yourad...@YOUR.REALM
    >> Where the AD admin is called yourad...@YOUR.REALM
    >>
    >>> Error: ldap_set_option failed (Unknown authentication method)
    >>> Error: ldap_connect failed
    >>> -- krb5_cleanup: Destroying Kerberos Context
    >>> -- ldap_cleanup: Disconnecting from LDAP server
    >>> -- init_password: Wiping the computer password structure
    >>> ________________________________________________
    >>> Kerberos mailing list Kerbe...@mit.edu
    >>> https://mailman.mit.edu/mailman/listinfo/kerberos

    >> --
    >>
    >> Douglas E. Engert
    >> Argonne National Laboratory
    >> 9700 South Cass Avenue
    >> Argonne, Illinois 60439
    >> (630) 252-5444

    >
    > Hi,
    >
    > This was the build I did, and in this order, with these options:
    > Kerberos 1.5.4:
    > ./configure --prefix=/usr/www/kerberos --without-krb4 --without-tcl --
    > disable-thread-support --enable-shared --disable-static
    >
    > OpenLDAP 2.4.8:
    > CC=gcc ./configure --prefix=/usr/www/libs/ldap --without-cyrus-sasl --
    > disable-slapd --disable-slurpd --with-tls=openssl --enable-shared --
    > disable-static
    >
    > Cyrus SASL 2.2.21:
    > ./configure --prefix=/usr/www/libs/sasl --with-openssl=/usr/www/libs/
    > ssl --with-dblib=none --enable-gssapi=/usr/www/kerberos --with-
    > gss_impl=mit -with-ldap=/usr/www/libs/ldap --enable-shared --disable-
    > static
    >
    > OpenLDAP 2.4.8 (again... cyclical dependency with SASL...):
    > CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    > usr/www/libs/sasl/include'
    > CC=gcc ./configure --prefix=$BLIB/ldap --with-cyrus-sasl --disable-
    > slapd --disable-slurpd --with-tls=openssl --enable-shared --disable-
    > static
    >
    > msktutil:
    > CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    > usr/www/libs/sasl/include -I /usr/www/kerberos/include'
    > ./configure --prefix=/usr/www/msktutil --with-tmpdir=/tmp --with-krb5=/
    > usr/www/kerberos --with-ldapdir=/usr/www/libs/ldap --with-sasldir=/usr/
    > www/libs/sasl --enable-shared --disable-statuc
    > Edit config.h - Add the lines to the top because configure failed
    > to detect this properly:
    > #define HAVE_GETHOSTBYADDR 1
    > #define HAVE_GETHOSTBYNAME 1
    > Edit Makefile - Change LIBS to be: LIBS=-lsocket -lnsl -lkrb5 -
    > lldap -lk5crypto -lsasl2 -lcom_err
    >
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

  9. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD

    On Mar 25, 6:38 pm, "Douglas E. Engert" wrote:
    > Share libs doing dynamic loads have always been a problem when not
    > built in /usr/local. You might need:
    >
    > SASL_PATH=usr/www/libs/sasl/sasl2 (Or whereever sasl2 is)
    > export SASL_PATH
    > LD_LIBRARY_PATH=/usr/www/kerberos/lib
    > export LD_LIBRARY_PATH
    >
    >
    >
    > PS wrote:
    > > On Mar 25, 5:19 pm, "Douglas E. Engert" wrote:
    > >> PS wrote:
    > >>> On Mar 25, 12:33 pm, "Douglas E. Engert" wrote:
    > >>>> PS wrote:
    > >>>>> On Mar 25, 12:00 pm, "Douglas E. Engert" wrote:
    > >>>>>> Your problem might be a bad version of ktpass.
    > >>>>>> Seehttp://support.microsoft.com/kb/919557
    > >>>>> That could be the case.
    > >>>>> But what about the fact mentioned that I created a keytab using ktutil
    > >>>>> addent as shown on the Solaris box, supplying the password, and I
    > >>>>> still get the same result?
    > >>>> The key is a function of the password and the salt. With DES the
    > >>>> password is concatenated with the salt which is usually the concatenation
    > >>>> of the realm and components of the principal name.
    > >>>> Since an AD account has only one password, but can have a UPN and SPNs,
    > >>>> the salt is based on the samAccountName.
    > >>>> So when you used the ktutil, it assumed a salt based on the principal.
    > >>>>> But when I kinit with this same password I > get the ticket?
    > >>>> Part of the pre-auth protocol is for the KDC to send the salt
    > >>>> to the kinit client. Kinit then combines the password and the KDC's
    > >>>> salt to generate the key.
    > >>>> If you want to see the KDC's salt, you can use a network trace
    > >>>> program like wireshark.
    > >>>> If you are going to have a lot of unix services or hosts, you might want to
    > >>>> google for msktutil. This uses OpenLDAP and Kerberos on Unix to create and
    > >>>> update keytab files.
    > >>>>> ________________________________________________
    > >>>>> Kerberos mailing list Kerbe...@mit.edu
    > >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
    > >>>> --
    > >>>> Douglas E. Engert
    > >>>> Argonne National Laboratory
    > >>>> 9700 South Cass Avenue
    > >>>> Argonne, Illinois 60439
    > >>>> (630) 252-5444
    > >>> Hi,
    > >>> I had to download and build Cyrus SASL, and consequently rebuild
    > >>> OpenLDAP, but I have a working msktutil (it seems).
    > >>> I tried to use the command as follows, with the result. Any ideas if
    > >>> I am doing something wrong here?
    > >> msktutil expects to be run as root (or user who owned the keytab)
    > >> with Kerberos credentials previous of an AD administrator who can write into
    > >> the branch of the tree where the account is located.
    > >> (Or if renewing the keytab, it can use the credentials in the keytab.)

    >
    > >> Tthe options we use are
    > >> -b base
    > >> -k kettab
    > >> -h hostname
    > >> -s service. i.e. host, HTTP, ldap, afs ... the service part of the principal
    > >> --upn upn
    > >> --computer-name unique-short-name as this must fit in 19 character
    > >> as it plus a "$" becomes the samAccountName. we uses a convention of
    > >> --

    >
    > >>> msktutil --verbose --create --hostname fc650dr.fc.fujitsu.com --
    > >>> server dc.corp.fc.local
    > >>> -- get_default_keytab: Obtaining the default keytab name: /etc/
    > >>> krb5.keytab
    > >>> -- get_default_ou: Determining default OU: CN=Computers
    > >>> -- init_password: Wiping the computer password structure
    > >>> -- finalize_exec: Determining user principal name
    > >>> -- finalize_exec: User Principal Name is: host/
    > >>> fc650dr.fc.fujitsu....@CORP.FC.LOCAL
    > >> Since you did not specify -s, "host" was used.

    >
    > >>> -- create_fake_krb5_conf: Created a fake krb5.conf file: /
    > >>> tmp/.mskt-9661krb5.conf
    > >>> -- get_krb5_context: Creating Kerberos Context
    > >>> -- try_machine_keytab: Using the local credential cache: /
    > >>> tmp/.mskt-9661krb5_ccache
    > >>> -- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not
    > >>> found in Kerberos database)
    > >>> -- try_machine_keytab: Unable to authenticate using the local keytab
    > >> Its trying to use the previous keytab to authenticate to AD which
    > >> does not exist yet. SO this is normal.

    >
    > >>> -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > >>> -- try_ldap_connect: Connecting to LDAP server: dc.corp.fc.local
    > >>> SASL/EXTERNAL authentication started
    > >> It should be using SASL/GSSAPI, did you build SASL with Kerberos?
    > >> It should say next:
    > >> SASL/GSSAPI authentication started
    > >> SASL username: yourad...@YOUR.REALM
    > >> Where the AD admin is called yourad...@YOUR.REALM

    >
    > >>> Error: ldap_set_option failed (Unknown authentication method)
    > >>> Error: ldap_connect failed
    > >>> -- krb5_cleanup: Destroying Kerberos Context
    > >>> -- ldap_cleanup: Disconnecting from LDAP server
    > >>> -- init_password: Wiping the computer password structure
    > >>> ________________________________________________
    > >>> Kerberos mailing list Kerbe...@mit.edu
    > >>>https://mailman.mit.edu/mailman/listinfo/kerberos
    > >> --

    >
    > >> Douglas E. Engert
    > >> Argonne National Laboratory
    > >> 9700 South Cass Avenue
    > >> Argonne, Illinois 60439
    > >> (630) 252-5444

    >
    > > Hi,

    >
    > > This was the build I did, and in this order, with these options:
    > > Kerberos 1.5.4:
    > > ./configure --prefix=/usr/www/kerberos --without-krb4 --without-tcl --
    > > disable-thread-support --enable-shared --disable-static

    >
    > > OpenLDAP 2.4.8:
    > > CC=gcc ./configure --prefix=/usr/www/libs/ldap --without-cyrus-sasl --
    > > disable-slapd --disable-slurpd --with-tls=openssl --enable-shared --
    > > disable-static

    >
    > > Cyrus SASL 2.2.21:
    > > ./configure --prefix=/usr/www/libs/sasl --with-openssl=/usr/www/libs/
    > > ssl --with-dblib=none --enable-gssapi=/usr/www/kerberos --with-
    > > gss_impl=mit -with-ldap=/usr/www/libs/ldap --enable-shared --disable-
    > > static

    >
    > > OpenLDAP 2.4.8 (again... cyclical dependency with SASL...):
    > > CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    > > usr/www/libs/sasl/include'
    > > CC=gcc ./configure --prefix=$BLIB/ldap --with-cyrus-sasl --disable-
    > > slapd --disable-slurpd --with-tls=openssl --enable-shared --disable-
    > > static

    >
    > > msktutil:
    > > CPPFLAGS='-I /usr/www/libs/z/include -I /usr/www/libs/ssl/include -I /
    > > usr/www/libs/sasl/include -I /usr/www/kerberos/include'
    > > ./configure --prefix=/usr/www/msktutil --with-tmpdir=/tmp --with-krb5=/
    > > usr/www/kerberos --with-ldapdir=/usr/www/libs/ldap --with-sasldir=/usr/
    > > www/libs/sasl --enable-shared --disable-statuc
    > > Edit config.h - Add the lines to the top because configure failed
    > > to detect this properly:
    > > #define HAVE_GETHOSTBYADDR 1
    > > #define HAVE_GETHOSTBYNAME 1
    > > Edit Makefile - Change LIBS to be: LIBS=-lsocket -lnsl -lkrb5 -
    > > lldap -lk5crypto -lsasl2 -lcom_err

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

    >
    > --
    >
    > Douglas E. Engert
    > Argonne National Laboratory
    > 9700 South Cass Avenue
    > Argonne, Illinois 60439
    > (630) 252-5444


    I still get the same result. I don't think it's linking issue here...
    though I have no doubt that something could be up with SASL in another
    aspect. Maybe I needed different compile options.

    I do think there is something wrong with the keytabs generated out of
    Windows 2003 SP1 server. I asked our AD admin to verify, and it looks
    as though we are running the bugged version. Of course we cannot
    simply uptake SP2, so I will have to find some other route. I guess
    Kerberos is out of our realm for now, so to speak.

    Thanks for your help in this matter Douglas.

  10. Re: Password incorrect while getting initial credentials using keytabon Solaris with AD



    PS wrote:
    > On Mar 25, 6:38 pm, "Douglas E. Engert" wrote:


    >
    > I still get the same result. I don't think it's linking issue here...
    > though I have no doubt that something could be up with SASL in another
    > aspect. Maybe I needed different compile options.
    >
    > I do think there is something wrong with the keytabs generated out of
    > Windows 2003 SP1 server. I asked our AD admin to verify, and it looks
    > as though we are running the bugged version. Of course we cannot
    > simply uptake SP2, so I will have to find some other route. I guess
    > Kerberos is out of our realm for now, so to speak.


    No, get the hot fix version of ktpass..., or use an older version from XP.

    >
    > Thanks for your help in this matter Douglas.
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

+ Reply to Thread