On Mon, 2005-11-07 at 21:12 -0700, Richard Megginson wrote:
Hello. Sorry I haven't replied earlier - we have a major release
coming
up. I think we chatted several months ago.
FDS is also committed to working with Windows. We have our Windows Sync
utility which uses DirSync to get the changes from Windows, and we use a
replication changelog to push the changes from FDS to Windows using
plain old ldap. For passwords, we have a password sync "plug-in" on
windows that intercepts the plain text passwords and sends them to FDS.
While the Windows Sync feature works ok, it's not perfect:
1) Relies on DirSync which up until recently was not a published spec
(if you know where I can get the spec, I would be grateful)
2) Doesn't sync everything - some groups on AD are "virtual" e.g. the
DomainUsers group - groups defined within the replicated suffix can have
members outside of that sufffix - no support for schema changes
(although we could just read the schema over LDAP as well, but that's a
lot more work)
We are making good progress on DRSUAPI synchronisation, but the best
sync AD -> Samba4 at the moment is the old netlogon, where we get the NT
password hashes.
3) Is hard to set up - people seem to have a devil of a time figuring
out things that the AD interface "hides" from you, like the DN of the
domain administrator and things like that
That really shouldn't be anything more than an ldapsearch or a
DsCracknames call on an autoconfiguration tool. (Samba4 has a
DsCrackNames client, which makes things easier :-)
4) No support for password policy and group policy - this will be
hard to do
We don't have these either yet, but neither looks too hard...
You guys seem to have solved 1 and 2. 3 I'll withhold judgement
on :-)
So I think we still need to exchange data between Samba4 and FDS. We
were trying to figure out how to solve 4 - we need to figure out a way
to have a common consistent password policy across PAM, LDAP, Kerberos,
and Windows. For Windows, we were going to try to figure out how to add
that information to the sync protocol. For Kerberos, I don't know if
you can get that information via gssapi, so we were going to try to use
Heimdal and replace the backend (I think new versions of MIT Kerberos
allow you to more easily plug-in another database backend).
Heimdal does have a good LDAP backend, and it is the hdb layer that I
have extended to build us the Samba4 KDC. (This is shipped 'in' Samba4,
and is linked into the main binary, reads the main database by default
etc).
So I guess there are a few ways for Samba4 and FDS to work together:
1) Use WinSync between Samba4 and FDS
If it is a windows interface, then we should eventually support it, but
it's not the way I want to crack this particular nut.
2) Use some other protocol (FDS multi master repl? LCUP? LDAPSync?
others?)
Messy, but possible.
3) Configure Samba4 to use FDS as it's database
This is where I want to go. I hate 'sync' systems with a passion, so I
want Samba4 to use FDS as much as possible. We can then provide KDC and
Windows Domain services on top of your database.
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team
http://samba.org
Student Network Administrator, Hawker College
http://hawkerc.net