directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrique Rodriguez <>
Subject Re: Convo with Adrew Bartlett (Samba 4 guy) about ADS and Kerberos
Date Tue, 25 Oct 2005 18:05:18 GMT
Emmanuel Lecharny wrote:
> abartlet : but Kerberos, NTP and everything else?
> ele-office : these are sub-projects
> ele-office : they are built beside ADS
> abartlet : other than love of java, any reason for re-impelemting those?
> abartlet : I found just the mods I made to Heimdal painful enough,
> reimplementing looked like a nightmare...
> ele-office : doing it in java seems one of the reason that led to a
> reimplementation.

The main reason is to have a common configuration mechanism, leading to 
a unified management experience for enterprise IT admins.  Specifically, 
I am thinking of DIT-backed configuration data, full hot-swap using OSGi 
for protocol-providers, dynamic notification of changes using the 
EventDirContext, and well-known management interfaces such as LDAP, JMX, 
and an embedded web UI.

> abartlet : anyway, I'm mainly just trying to get good contracts with
> various ldap directory implementors, because I expect there to be strong
> demand for Samba4 as a frontend to various ldap backends
> ele-office : it could be interesting to see how samb4 can use ads as an
> ldap backend.
> ele-office : and I think it should be really easy.
> abartlet : yes and no, Samba4 has some very particular requirements for
> it's LDAP backends
> ele-office : like ?
> abartlet : hosting the AD schema
> abartlet : and behaving like AD in general
> abartlet : (there are certain operations, such as an add, which are
> filled out by a server-side template)
> abartlet : and various operational attributes to be generated etc
> ele-office : I see.
> ele-office : AD use a lot of operationnal attributes
> ele-office : Sorry, I don't know enough about Samba to be able to broing
> you some lights about the way to use ADS as a ldap backend :(

We will do whatever we can to behave more like AD.  Just let us know! 
My talk at ApacheCon US 2005 in December will cover as much as we have 
working by then w.r.t. using ApacheDS for SSO in MS/Mac/Linux 
environments and the aforementioned OSGi-based configuration.

> abartlet : I'm also just trying to find out where this project is at
> ele-office : currentlmy, we are trying to deliver the 1.0 version of the
> core Ldap Server.
> ele-office : DNS and Kerberos sub-projects will be delivered almost at
> the same date.
> ele-office : their are other sub-projects, too (Penrose, Mitosis, ...)
> abartlet : how compliant it the kerberos server?
> ele-office : it is supposed to be fully compliant
> ele-office : so does Ldap
> abartlet : the small amount of stuff I looked at looked like it was
> hardcoded for the old des enc types

Other than admittedly inflexible config, Kerberos does work for SSO. 
And MS only supports RFC 1510 and the "old des enc types."  I use it 
regularly for Linux and MS SSO.  Also, Changepw works, too.  I know, 
Changepw seems minor, but if you are going to do SSO you should have a 
secure way to set/change passwords.  Admittedly, NTP is the stepchild 
here, but it was easy to do and, again, will use the same config 
mechanisms and NTP is require for Kerberos/Changepw.  Further down the 
road, I'd like to add NTP authentication which will further benefit from 
the re-implementation.  Similarly, DNS gains from a re-impl w.r.t 
Kerberos-secured DNS and the aforementioned config mechanisms.

DNS currently serves record out of a single DIT subtree.  I hope this 
week to release multi-zone catalog capability and then quickly add 
multi-realm capability to Kerberos.  DNS will serve SRV records so I'd 
like to work before ApacheCon to make sure KDC Discovery is working.  It 
should work but I haven't had a chance to try it.  Right now with 
Windows 2003 you have to configure on each workstation the KDC and 
Changepw servers but we should be able to serve this using SRV records.

Much of the config is defaulted to "old enc types" but certainly we know 
how to make configuration more flexible.  In fact, I am reworking all 
the config, as we speak, with an audit to ensure flexibility and to have 
the option of putting all config in the DIT.  OSGi provides a standard 
service called Config Admin, which is DIT backed in the sandbox.  I 
admit some of the p-p config is not very flexible, but I delayed such 
work since I knew we'd be reworking things for the Config Admin's 
dynamic semantics.  But first, I had to implement the Config Admin 
backed with the DIT and Alex had to add the EventDirContext, so changes 
would work in the dynamic model that OSGi uses.  Yesterday and today's 
DIREVE issues (from me to Alex hehe) were all from DIT-backed config 
problems I found.

Also, some of the enc types are subject to US export control (abartlet 
is AU), for example AES, but they are impl'd in the JDK or Bouncy 
Castle.  There are interfaces for trivially adding new enc types, so, 
again, I have not totally completed this work but it is easy to add.  I 
have a JIRA issue open to audit Kerberos for the RFC 4120 update which 
came out in July.

> ele-office : The target is to deliver a server that can pass the
> Compliance tests of the OpenGroup
> ele-office :
> ele-office : Kerberos is still a work in progress ;)
> ele-office : it's version 0.5.1
> abartlet : are the developers on the kitten lists?  
> abartlet : (the kerberos working group)
> ele-office : I don't know ;) I'm not working on kerberos, and Enrique,
> the one who is working on it with Alex
> ( is not
> currently connected ...

Yes, I follow Kitten, GUAM, and other related IETF working groups such 
as SAM and I am a representative to OATH where I either follow the email 
or dial-in on the calls.  Kerberos currently supports SAM types (with 
even more heinous config) but you can actually use Kerberos and mobile 
phone tokens to do 2-factor authentication.

> -- Emmanuel

View raw message