problem with 2003 krb and mit krb integration with mozilla thunderbird on a multiple realm scenario

Tiago Quadra tquadra at
Mon Mar 20 09:22:12 EST 2006

Dan Perry wrote:
>> What we are stating to do is use a program, msktutil, that will use LDAP to
>> added the account and add the UPN and SPNs, and update the keytab. Its
>> still
>> under development, and I hope the author will publicize it more in the
>> future.
>> [I am BCC'ing him on this note.]
> I've been meaning to send a note out to a Kerberos/Active Directory interop
> group for a little while now...
> If you're interested, I have a tool called msktutil, which is designed to be
> a 'better' ktpass.  You can download the source from:
> This tool was written about a year and a half ago, and we use it regularly in
> our production Linux cluster.  It should build with MIT Kerberos 1.3 or
> later, a recent openldap library (I've used 2.2 and 2.3) and a recent SASL
> library.  It also should build with heimdal 0.7.   If the MIT folk like this
> utility, I'd be happy to work on donating this code to their project and
> having it integrated into their distribution.
> msktutil will let you create computer accounts, service principals, and
> keytabs directly in active directory.  This tool will create a computer, and
> associated one or more principals with that account, for example you can
> create a computer account called 'linux-host' and associate principals such
> as host/linux-host.domain and ftp/linux-host.domain with that computer
> account.  In following with active directory's model, msktutil can create one
> primary principal (the UPN), and as many service principals as you desire.
> Msktutil also includes some flexibility (Thanks to recent feedback I've
> gotten from Douglas Engert) in naming computer accounts.  For example, you
> may wish to have one principal for host/fqdn, and another for http/fqdn, and
> you may wish for those principals to be separate for security reason.  With
> msktutil, you can use the --computer-name option to specify different
> computers for the two services, i.e. server-host and server-http.  
> Tiago, you may want to give msktutil a shot.  It should be much easier to get
> working then ktpass.
> -Dan 

Hey guys,

I just want to thank you all for the help... I'm glad to say the 
scenario described worked fine.

I'll be writing a small how to showing how to reproduce... it's actually 
very simple...
Setting the default realm and default cyrus domain to the Windows Server 
2003 REALM did the trick... Apart from that, the only additional thing 
(from the documentation that already exists) I needed was to create the 
principal krbtgt on the MIT KDC for the thurst with "ank ... -e 

I can SSO with Thunderbird/Firefox on Cyurs/Apache using SSPI 
credentials got from the Windows XP logon Windows 2003 Server.
It's also possible to use GSSAPI credentials got from MIT Kerberos 
Client for Windows, and SSO to Windows 2003 Server DC resources...
Both using principals on MIT KDC.

It'll probably work with any Client/Server combination that supports 

Both scenarios may be useful to migrate from Windows to Linux or from 
Linux to Windows and for large sites with many users and running 
applications that rely on GSSAPI/Kerberos. I found it more easy and 
flexible to deal with MIT KDC and tools then Win2k3 KDC (not mentioning 
probably more secure? less chances of flaws...);

The only thing I'm still missing was the ability to change the password 
for the MIT Kerberos principal from the Windows XP "ctrl-alt-del" 
menu... it works with the REALM with the default kerberos port for admin 
server and kpasswd. But I have more then one realm on MIT KDC and each 
REALM must use a different port... I didn't find a way to setup the port 
on Windows...

The ksetup command don't show any option to specify the port address and 
I can't find any Microsoft documentation that shows how to do it.... may 
be directly on the registry?
We are still testing the impact on login scripts and gpo when the user 
are logged on using the MIT KDC principal...

Best regards,
Tiago Quadra.

Esta mensagem, incluindo seus anexos, pode conter informacoes privilegiadas e/ou de carater confidencial, nao podendo ser retransmitida sem autorizacao do remetente.

Portanto, se voce recebeu esta mensagem por  engano, por favor, nos informe respondendo imediatamente a este e-mail e em seguida apague-a.

As empresas do GRUPO MULTIPLAN nao se responsabilizam por conclusoes, opinioes, ou outras informacoes nesta mensagem que nao se relacionem com sua linha de negocios.

More information about the Kerberos mailing list