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)
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
4) No support for password policy and group policy - this will be hard to do
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).
So I guess there are a few ways for Samba4 and FDS to work together:
1) Use WinSync between Samba4 and FDS
2) Use some other protocol (FDS multi master repl? LCUP? LDAPSync?
others?)
3) Configure Samba4 to use FDS as it's database
Other ways? I'm certainly open to suggestions.
Andrew Bartlett wrote:
As a member of the Samba development team working on Samba4, I'm
interested to try and gain some more integration with directory vendors,
as we work out how our projects might work together.
I see Samba4 as a powerful addition to any directory or identity
management solution, able to provide an AD Domain Controller-like
front-end to Native windows clients. In particular, this is about
deploying non-Microsoft directories on windows networks, without falling
back to the 'MIT compatibility mode' or inter-realm trusts to handle the
'single sign on' and 'identity management part of it.
Samba4 is at this time able to act as an AD domain controller, including
providing LDAP, Kerberos (including the PAC) and RPC logon services. We
are accepted as AD by Win2k, WinXP and Win2k3 clients. (I am working on
Mac/Samba/similar clients).
While Samba4 includes it's own LDAP server, we have made extensive
provision to back our data onto something like Fedora Directory, but I
want to work with fellow interested developers on the details: What
would be reasonable for each end of the connection to do, particularly
as we try and map behaviours/schemas/expectations.
Andrew Bartlett
------------------------------------------------------------------------
--
Fedora-directory-devel mailing list
Fedora-directory-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel