Thursby’s ADmitMac is a full-featured SMB/CIFS client that contains a lot of great features to hook Mac OS X into an Active Directory infrastructure. Be aware, though, that there is a downside involved. Thursby chose to implement a different method of handling resource forks on non-AFP filesystems than Apple uses in its samba-based SMB client. Basically, Thursby’s method takes advantage of multi-fork-savvy filesystems (like NTFS) whereas Apple’s doesn’t.
The upshot of this is that if you have two Mac clients, one using ADmitMac and the other using the "stock" SMB client, both accessing an SMB share, neither will be able to see resource forks saved by the other system. This is no big deal for some files (notably those with a known DOS-style 3-letter filename extension like ".doc" or ".xls"), but it can make other files completely unusable. For example, Eudora files rely on the type/creator codes in the resource fork; without the resource fork, Eudora doesn’t know what to do with the various files.
I quizzed a Thursby engineer on this incompatibility, and he pointed out that their DAVE product, which was the first SMB client for Macintosh, used this method because it adhered to Microsoft’s Services for Macintosh standard. They are simply carrying on the tradition of doing it the Microsoft-recommended way.
This incompatibility is a huge issue that Thursby seems reluctant to address. Thursby’s implementation may be superior to Apple’s on technical grounds; nonetheless, they need to either convince Apple to do it their way, or change ADmitMac (or at least offer an administrative option) to do it the Apple way. As it stands now, unless sysadmins go with an "all or none" approach to ADmitMac in their organization–now and into the foreseeable future–they’re asking for trouble. That’s an expensive prospect.
by 
I’m glad that .DS_Store is now optional on network volumes as it isn’t required by anything to be able to use a directory. It’s just icon and placement data.
—
Breaking my server to save yours.
Josh Wisenbaker
http://www.afp548.com
The problem with that is that Active Directory schema changes are rather
permanent. 2003 allows you to ignore them, but once you change an Active
Directory schema, restoring from backup, or reformatting and reinstalling are the
only ways to undo them.
—
John C. Welch Writer/Analyst
Bynkii.com Mac and other opinions
[email protected]
Even though people talk a lot about the irreversibility of schema changes, most
organizations don’t seem to care, or don’t realize that a large number of apps
already do this with AD.
Exchange alone has some 400 schema mods that it does, plus a lot of other
software that uses AD for authentication will do the same, they just might not
be so up front about it. They are much more
Apple has registered the OIDs that they are using now, so the impact of a
schema mod, even if you stop using the Apple attributes is very minimal.
—
Changing the world, one server at a time.
Joel Rennich
http://www.afp548.com
A number of 5000+ machine sites have gone down the road of schema
extension to support collections of 100-1000 OS X systems. I’ve worked with
and talked to big hi-ed places and large corporate environments that have done
this.
You’re right, that it’s not always easy. A lot depends on the management and
the admin staff, but there are organizations out there that are happy to do
things like this.
—
Changing the world, one server at a time.
Joel Rennich
http://www.afp548.com