"Seamless" Integration of Mac OS X w/ Active Directory

eexlebots asks: "I work for a small college which has a few Mac OS X 10.2 machines and a fairly standard Active Directory setup. Actual deployment of these clients rides on getting them to authenticate at login to our Active Directory server. Apple has stated that this is possible (easy! seamless!) with Jaguar without the use of an additional Mac OS X server, but I have found the case to be quite different. It is possible, but not without a good deal of nightmarish configuration issues. Documentation? HA! No sign of it anywhere on Apple's site. I'm not alone: at macwindows.com I found a good many people who think that Apple's claims of seamless Windows Network integration to be a bad joke and nothing more. I was wondering who else out there is having this problem, and what they have done to solve it."

Comments

Winbind???

[Anonymous Coward]

Can't you just use Winbind from the SAMBA project to use AD authentication? Just configure Winbind to point to your Domain controller and setup NIS to work with it.

Or am I off base? I've done this on FreeBSD i386 boxes so it should not be difficult, unless Apple has mucked up logins.

Why not Samba?

[bdowne01]

I'm stating this at a very high-level perspective, but I know Samba is an actual component of OS X Server, and it is known to compile and install on OS X perfectly.

So why not use Samba for integration to Active Directory? I'm not perfectly clear on the details of doing so, but I'm pretty sure you can use Kerberos to hook up to an AD domain, and go from there.

Any reason not to try? After all, Unix folk are generally pretty adamant about not reinventing the wheel :)

MacOS X and linux

[rkt]

If someone can make this work with MacOS, I'm sure linux/unix is not far away. Solaris supports LDAP and I'm sure so do a lot of other Unix os... and the fact that Active Directory can be accessed using LDAP queries does make you wonder why we don't have any linux/unix server connecting to Active directory as of today.

Active directory, just like any other MS stuff likes to maintain its own standards and its hard to get inside documentation on it on the web.

Solaris LDAP and linux LDAP implementations have a lot of problems. Its just not ready for Enterprise class networking. I sat on a simple netgroup bug for months before SUN came out with a patch. And linux doesn't even support netgroup as cleanly as Solaris yet.

Its a pain.... if MacOS X can solve all these hiccups ( and if they do manage to come out with a documentation) I'm sure it will inspire the other Unix environments.

rkt

But About the Content of the Piece...

[spiedrazer]

We have been struggling with OSX's 'seamless' integration with Novell and are having similar results. Our problems may stem more from Novell's supposed "Native File Access" support than with Apple's side of the connection, but it's been just as frustrating.

If Apple really wants to make OSX compatible with the entrenched NOS's out there, they need to hire a few Active "Directory" and Netware engineers and teach them about the MAC as opposed to the other way around.

File Corruption with Jaguar and SMB Sharing

[fridgepimp]

I currently work in a smallish office with about 15 workstations and 3 or 4 different file servers. Our workstations are about 70% Mac and 30% Windows. The servers run FreeBSD 4.x, Linux (with a 2.2.x kernel) and Windows 2000/XP. On the FreeBSD/Linux servers we run two different versions of Samba (2.2.x & 2.0.x).

No matter which server we connect to, if we copy files from the Mac to the server using SMB as the protocol, we experience a significant amount of file corruption (it appears to be that there are just chunks of the file that don't get copied). It is repeatable, but doesn't happen every time. This is a serious inconvenience. I should also point out that we did NOT have this problem prior to upgrading to 10.2 (we also have upgraded to 10.2.1).

I've have sent numerous reports with details to Apple with no response.

--fp

Active Directory vs. SMB?

[Andy Dodd]

What exactly is the difference between these?

Or is AD just the authentication portion of SMB?

I know on RedHat systems, you can choose the pam_smb_auth PAM module to authenticate against a Windows domain controller. Pop in your domain and the server name, pam_smb_auth handles most of the rest. You still need a local entry in /etc/passwd with the user's uid/gid/homedir (It IS possible to get around this with the "nolocal" option, but needless to say it only works for a limited subset of services), but that entry doesn't need a password set, just * (Which would disallow logins normally, in this case if pam_smb_auth clears the authentication, you can log in)

I have this set up on a Linux box at work - At the moment I need to use adduser to create local accounts, but I don't need to give the users passwords - They use their current domain userid/pass.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Jaguar and windows network browsing

[sjonke]

Jaguar's alleged Windows network integration is lacking to say the least. In my case it is that windows network browsing is limited to your subnet only, making it nearly useless. I.e. you don't see and can't get to (even nearly) everything when you browse. You CAN get to anything via typing in an appropriate smb URL in the "Connect To Server..." window, but obviously then you have to know the server is there.

Mind you, I have little to no need to do any of this anyway so it isn't a big deal to me, but if they're going to advertise seamless windows network integration then it ought to be that. I want $1 back for that alleged feature.

Re:Well it's not that hard to fix. OS X/NDS here

[Havokmon]

because if you use LDAP or NDS you end up with the same nightmarish configuration issues, except now the issues are with the windows machines, which are probably 90% of his clientelle.

Ehrm. Not only do I have Windows machines, I have an OS X box, and my workstation is Linux.

Now, the windows boxes DO have random crashes regarding the TCP/IP stacks (Exception 0E), but that has nothing to do with Netware/NDS.

Stop spreading FUD, I've run NDS for 5 years, and logging into the server is not an issue. Sure, there can be other issues (client-side caching of shared documents - umm turn it off), but nothing that is specific to NDS.

Plus, with NDS, you don't even need Netware. (Oh, and it's also LDAP v3, so we've used it for web app auths also)

It Doesn't Work, Yet. I've Tried.

[Spencerian]

Apple, in its attempts to get into more enterprise accounts, has not learned that system administrators require documentation ad nauseum. They wrote their documentation for AD in the old 10.1 Server AD/LDAP PDF and in their System Administrators guide for 10.2 Server much too simply.

Recently I worked with Apple to receive an Xserve for two tests--getting a Macintosh to authenticate by AD (which is an LDAP superset) from login, and to provide authentication on file shares from AD using the Connect to Server command, where the shares would be provided by the Xserve.

I had no success in getting anything to work with 10.1 Server. After getting 10.2 Server from Apple, we had luck in getting authentication for file shares working. Part of the problem involved how LDAPv3 (the main component in Apple's Open Directory) relates to the AD schema. I'm not an AD expert, but Apple has got a "not-invented-here" mindset here; the LDAP components don't match up with with sysadmins expect. I was unable to get the login authentication component working at all.

As a result, I couldn't recommend an Xserve for my customers, and stuck in Services For Macintosh, a component in Windows 2000 Server that provides the same authentications to file shares by AD without the Xserve acting as a middleman for file sharing. It's got its own issues, but at least it worked as advertised; it took us only 5 minutes to set this up on a working W2K server.

Apple MUST have the documentation and software working and tested before making claims. This is a completely unacceptable way to sell their wares, and is worsening an already bad reputation for many in IT.

Just so you know, Macintosh system integration is my business, so I feel quite justified in flaming Apple for such a bad implementation. It's not really their technology, but how they sold this currently-snake oil concept to Mac professionals.

Re:It Doesn't Work, Yet. I've Tried.

[jafac]

This very much resembles the typical situation where two vendors have a solution that's supposed to work "in theory" but one or both implementations of the "standard" are broken; ie- there's some undocumented behavior.

Quite often, in these situations, Vendor B has set up a test environment, and it works in their lab. But that only matches about 20-30% of the environments you'll hit in the field. (as I've seen, you typically see stuff like this breaking on the Microsoft side, mysteriously dropping names, losing connections, failing to authenticate where there's supposedly a trust - etc. it can be fragile on "difficult" networks).

It's not enough for Vendor B to say that their solution works with Vendor A's solution - it has to be tested, but then you get it out into the field and you run into these "edge cases" and it doesn't work - and the ONLY way ANY vendor can fix it is to plow through it with onsite visits with engineers, LAN analysis, debugging, etc. It's very costly and time consuming. In the end, Vendor B will code around the problems, (or try to get Vendor A to code around them) and the system becomes more robust. This is what is known as a "MATURE" product.
An immature product "should" work, and does not when you hit an edge case, and the vendor hasn't "worked it out" yet. Only the companies that "been there done that" have "mature" products. We need to ALL remember that OS X is just a year or so old. Apple has been in the server market (in this incarnation) for less than 6 months. Apple does not have the field force of say, IBM, Sun, or CA. It's going to take time for them to grow the expertise to mature THIS solution, and learn how to mature their other solutions.

This is why the CIO's out there tend to shun products from smaller, newer companies. No matter how cool, great, whiz-bang, or free the product is - it it's going to be costly to implement if it, and the support organization behind it, aren't MATURE.

Yes - the fault lies with Vendor A in this case, most likely, for using a non standard implementation (as Microsoft is FAMOUS for - on purpose, to get the checkmark for compatability, but actually preventing interoperability, in order to persuade people to buy into homogeneous computing - based on their system) - but at the end of the day, if Vendor B wants to play in this market, they've got to mature. Fact of life. Not pretty, just the fact.

not to be a complete wag....

[otis wildflower]

... but how about porting your AD environment to Samba + LDAP on a unix-based Samba PDC?

Save lots of $$$ on server licenses, and Win2k works fine in NT4 backwards-compatibility mode..

Depends on how many people, departments, etc.. But it could be a cost-effective solution.

As long as M$ isn't paying your college off, of course ;)

Hey, man. I only work here, you know?

[tulare]

And, while I understand that having Apple say "its easy" makes you want to blame them, you really ought to blame MS or yourselves for purchasing MS technology.Believe me, if it were my choice, we wouldn't have a single Windows machine on our network, either server or client. But it's not my decision to make. Given the reality that I am in a Windows shop, I do my best to make things work right. And, so far, OS X clients only work marginally well. Users can manually mount NT shares using their AD auth, but we'd relly prefer to see login screens at bootup authing against the AD. And that's where the problem lies. I agree that the problem is probably M$, but what can I do?

Covered on the Mac-Mgrs mailing list.

[Anonymous Coward]

Mac-Mgrs (Macintosh Managers) a mailing list in existence for over 10 years, has covered this issue, and every other issue regarding managing Networked MacOS machines in a multi-platform environment.

They keep an archive, which is available for public searching. Go there, and search the "new" archives (post April 2000) for "Active Directory."

The list is an excellent resource for troubleshooting MacOS (Classic & X) management issues.

Mac-Mgrs also has probably the best s/n ratio on the Internet, as well as throwing a great geek party at MacWorld Expo twice a year. =)

Re:Well it's not that hard to fix. NDS != Evil.

[Openadvocate]

I had a excellent Novell experience today. :)
I just installed a demo of Netware 6 today, I was amazed by the number of programs coming with the server as default, damn. Just look at the web admninistration.

When talking NDS, I discovered that now that Novell runs PHP,MySQL,Perl there is a greater reason to run apache web servers on it.
And what was even better, you can now authenticate users against your NDS in apache. cool. Just like you would use a .htaccess file, you can point it to the NDS directory instead, very cool indeed, it would look something like this.
-----
AuthType Basic
AuthName "Secure_Site"
AuthNDSTree TREE_NAME
AuthNDSContext .organization [.context.organization]
AuthNDSRequireSSL [on|off]
require valid-user
order allow,deny
allow from all
---

It was very cool to see my php/mysql applications running on a netware server, I didn't need to change anything in the code, I imported my SQL data into MySQL and it was running.

This does work just fine with 10.1.5 and 10.2!

[Anonymous Coward]

I have setup OSX clients to authenticate and automatically mount their home directories using both 10.1.5 (LDAPv2) and 10.2 (LDAPv2 or v3). It works great once you have it setup correctly.

Just to be clear, this is with *no* replication of account information between AD and OSX. All account information is stored in AD and stays there. The clients don't store any user information.

Also, I have done this with both win2k and OSX servers for home directories.

The article from Apple (OSX integration w/ AD) is a good start for the basics. Much of it applies when moving forward to 10.2, except that many of the setup screens are different.

My main recommendation is to *not* use their schema definitions. The reason for this is that they tell you to piggy back on existing attributes in AD. While this is nice from the standpoint of not having to edit the schema much, other MS applications may need those attributes for their own use. For example, they tell you to put the home directory URL (an xml description of the home directory location) into the "HomeDirectory" attribute. This, however, is used by MS clients to find their home directories. If you have users that cross between windows and mac, it won't work.

Instead, I'd take the schema from the Open Directory service which comes with OSX Server and pull out the attribute names and OIDs from there to use. The only thing it is missing is an attribute/OID for the "NFSHomeDirectory", which they recommend you use "UserSharedFolderOther".

Also, don't add the attributes directly to the existing user class. Create another class with those attributes and add it into user class as an auxiliary.

I agree that the docs really need alot of updating to make this possible for the average admin to deploy. However, Apple has provided the technology to have a very nice integrated solution once you know what you are doing.

This solution is actually fully deployed at one public school in Massachusetts and partly deployed at another one (they are still in testing). Students are able to sit down at any OSX system and have their desktop, preferences, and documents follow them around seamlessly.