Creating an MIT style keytab for an existing Windows AD membercomputer

Douglas E. Engert deengert at anl.gov
Wed Jul 23 15:30:09 EDT 2008



Paul Moore wrote:
> "It could then impersonate any user to the machine"
> 
> Can you explain that. I want to make sure I understand all potential
> kerb threats, this is a new one to me. 

This is at the heart of Kerberos. Client and server trust KDC and trust
KDC to give service ticket to client usable at server.

The server trust the KDC only because the KDC and server share a secret,
the key in the keytab. If someone else knows the key of the service
principal, they could create a service ticket claiming to be any client,
and present it to the server. The server will decrypt the ticket
assuming it came form the KDC introducing the client to the server.

See http://www.ietf.org/rfc/rfc4120.txt  section 3.2.3

> 
> 
> 
> 
> 
> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf Of Douglas E. Engert
> Sent: Wednesday, July 23, 2008 7:19 AM
> To: Edward Irvine
> Cc: kerberos at mit.edu
> Subject: Re: Creating an MIT style keytab for an existing Windows AD
> membercomputer
> 
> 
> 
> Edward Irvine wrote:
>> Hi,
>>
>> I'd like to find out if there is any way to extract a HOST keytab for 
>> a windows computer that is already a member of an active directory 
>> domain.
> 
> Do you have to be use the Windows "host" principal? Can your application
> use a different principal, like HTTP or LDAP or make up your own.
> 
> Then your application server has its own keyfile, and does not need
> access to the one use by Windows for login. There are security issues
> with letting an application access this key. It could then impersonate
> any user to the machine.
> 
>> A Java developer I look after wants to do the single sign on thing to 
>> his web application. Our environment is a mixed Active Directory and 
>> Solaris environment.
>>
>> By creating a new user in active directory, and mapping the user to a 
>> service principle using ktpass.exe, we now have SPNEGO single sign on 
>> working between the clients Internet Explorer and the JBoss server on 
>> *Solaris*. So far so good.
> 
> A common misunderstanding when reading the Microsoft docs Kerberos and
> service principals has to do with the term "user".
> The "user" account referred to with ktpass, is an ldap term for the
> objectclass user. Kerberos service principals need a "user" account in
> AD. This user account has nothing to do with real users who will
> authenticate to the service.
> 
>> The developer, who uses a Windows workstation that is part the Active 
>> Directory domain, now wants the SPNEGO authentication to work in his 
>> own windows workstation - and for that to work I need to get the 
>> keytab for the host/pingname.of.host at KERBEROS.REALM.NAME
>>
>> A quick LDAP lookup of his workstation in AD reveals that it already 
>> has a servicePrincipalName of HOST/pingname.of.host - so presumably I 
>> can extract the keytab somehow. But how?
>>
>   Not really. They also change the keys every so often, so you don't
> want to copy it.
> 
> If your Java application needs to act as a server, and really use the
> "host" service principal, can you use some Java to SSPI-service class?
> (Don't know if one exists.) (GSSAPI and SSPI use the same protocols.)
> 
>> I don't personally have admin access to the AD domain, but I work with
> 
>> the folks who do.
>>
>> Eddie
>>
>> ________________________________________________
>> 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