Password incorrect while getting initial credentials using keytab on Solaris with AD
PS
pseely at gmail.com
Wed Mar 26 09:15:19 EDT 2008
On Mar 25, 6:38 pm, "Douglas E. Engert" <deeng... at anl.gov> 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" <deeng... at anl.gov> wrote:
> >> PS wrote:
> >>> On Mar 25, 12:33 pm, "Douglas E. Engert" <deeng... at anl.gov> wrote:
> >>>> PS wrote:
> >>>>> On Mar 25, 12:00 pm, "Douglas E. Engert" <deeng... at anl.gov> 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... at mit.edu
> >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
> >>>> --
> >>>> Douglas E. Engert <DEEng... at anl.gov>
> >>>> 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
> >> <service>-<first-part-of-hostname>-<second-part-of-hostname>
>
> >>> 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.... at 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... at YOUR.REALM
> >> Where the AD admin is called yourad... at 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... at mit.edu
> >>>https://mailman.mit.edu/mailman/listinfo/kerberos
> >> --
>
> >> Douglas E. Engert <DEEng... at anl.gov>
> >> 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... at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> --
>
> Douglas E. Engert <DEEng... at anl.gov>
> 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.
More information about the Kerberos
mailing list