On Mar 25, 6:38 pm, "Douglas E. Engert" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> wrote: > >> PS wrote: > >>> On Mar 25, 12:33 pm, "Douglas E. Engert" <[EMAIL PROTECTED]> wrote: > >>>> PS wrote: > >>>>> On Mar 25, 12:00 pm, "Douglas E. Engert" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos > >>>> -- > >>>> Douglas E. Engert <[EMAIL PROTECTED]> > >>>> 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/ > >>> [EMAIL PROTECTED] > >> 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: [EMAIL PROTECTED] > >> Where the AD admin is called [EMAIL PROTECTED] > > >>> 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 [EMAIL PROTECTED] > >>>https://mailman.mit.edu/mailman/listinfo/kerberos > >> -- > > >> Douglas E. Engert <[EMAIL PROTECTED]> > >> 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 [EMAIL PROTECTED] > >https://mailman.mit.edu/mailman/listinfo/kerberos > > -- > > Douglas E. Engert <[EMAIL PROTECTED]> > 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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
