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

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:

http://www.pppl.gov/~dperry/msktutil.tar.gz

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
des-cbc-md5:normal"

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
kerberos...

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.

________________________________________________
Kerberos mailing list Kerberos@xxxxxxx
https://mailman.mit.edu/mailman/listinfo/kerberos

.

Relevant Pages