Ever have a question about how to make UNIX hosts and/or services place nicely with Microsoft's AD domains or vice-versa? Then this session is for you. Stop by and bring your hardest or strangest UNIX/Linux/AD interoperability problems.
Gerald is southern, and pronounces it sam-bah (rhymes
with ham
), not sahm-bah (rhymes with
lawn
). But he says it doesn't really matter.
Garald knows he'll get stoned for saying this, but he thinks AD is actually fairly decent directory services implementation. It's just unfortunately that it's proprietary and comes with vendor lock-in.
AD is more than just a Kerberos, LDAP, and CIFS server shoved together. It's not just the components; it's the infrastructure for how they work together. That's one of the reasons why using Samba as a Domain Controller can be challenging.
You can run winbind without running smbd at all.
The Samba 3 team focuses on current features; Samba 4 is more along the lines of theoretical development.
Microsoft has far too much invested in AD to change. While they'll continue to make incremental changes, they can't make any far-reaching, crank-the-major-version-number changes. This actually is going to somewhat tie Microsoft's hands in terms of what they could do to deliberately break Samba.
Things get done in Samba because vendors pay the Samba team to add features they want. Most of the developers are funded. The reason why they never finished the NT4 Domain Controller implementation is because there isn't any vendor who wants to ship it.
Gerald isn't really concerned with domain controllers; he's happy to let those continue to run Microsoft code. The real opportunity to erode Microsoft's market share is by chipping away at their fileservers, because for virtually all organizations, there are many more fileservers than domain controllers. That's what the Samba team focuses on.
We suck at making tools; we really do. Swat is awful. The reason why swat can never be right is because when you let the administrative features drive the framework, you wind up with bad framework. The plumbing needs to be built first; the administrative features need to be built on top of it.
And the reason why Samba has never done this is because Samba is a monolithic piece of code. It shouldn't be; things should be broken out into components and shared libraries. The reason why they haven't done this is because it's
Samba has less than a dozen active developers, which is pretty amazing, considering the amount of code they ship.
It's only a matter of time before someone writes an open source group policy agent for Unix; the current inhibitor is the Windows tools you'd have to create at the same time.
You need POSIX ACLs to support Windows ACLs, and you need extended attributes to do ACL inheritance. So, you need to mount the filesystem with those options.
Apple's smbfs filesystem is proprietary; it has no relation to anything related to Samba.
The idmap backend is readonly, which is problematic, because you can't create the builtin domains.
You need to specify an alloc backend for DOMAIN, so that it can create accounts in the BUILTIN domain. Look at the idmap_ad man page for examples.
The RID plugin is done; there's nothing else to be done with it. The nice thing about the AD plugin is that you have more flexibility. Gerald likes the ad plugin.
3.0.26 will have support for one-way trusts, complete support for transitive trusts, and offline logon support (via cached logon credentials). There are a lot of other fixes that are going into 3.0.26.
The diff between 3.0.24 and 3.0.25 is 200,000 lines. They're following the Linux kernel development model, although they arrived at the same conclusion independently.
You really can't do any type of sparse
idmap mappings; it's
in all-or-nothing approach.
User mappings occur after authentication when you are a member of a domain, but before authentication when you're running standalone.
You can go to the index of my Usenix notes.