Password incorrect while getting initial credentials using keytab on Solaris with AD

Douglas E. Engert deengert at anl.gov
Tue Mar 25 16:19:47 EDT 2008



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.com 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: youradmin at YOUR.REALM
Where the AD admin is called youradmin 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           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

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



More information about the Kerberos mailing list