"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

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 :)

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

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.

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?

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.