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 FDS2) 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-devel
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
