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
Attachment:
signature.asc
Description: This is a digitally signed message part
