Slashdot Log In
"Seamless" Integration of Mac OS X w/ Active Directory
Posted by
Cliff
on Tue Nov 05, 2002 01:57 PM
from the more-seams-than-your-average-dress dept.
from the more-seams-than-your-average-dress dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Title != message (Score:4, Informative)
How to do it with OS X 10.2 (Score:5, Informative)
Browse to
Slap back wallop, you should now be authenticating with an AD server, seamlessly it is. Works Good for me, I dont like AD, but I really dont care, it authenticates me thats all I need, keeps management happy too, they love spending that money!!!.
T
Parent
Well, (Score:3, Insightful)
Actually, it's not that bad for MS. (Score:3, Insightful)
Re:Actually, it's not that bad for MS. (Score:3, Informative)
The deal is that you're licensing a certian number of "workstations" so as soon as you install Office you've got another workstation added to your network and have a certain minimum configuration you have to buy. Usually it's a copy of Windows (XP now), a copy of Office (whatever flavor you standarize on), and maybe some other standard thing like Project.
So just to add Office to a Mac under MS's licensing scheme it'll cost you maybe $800. YMMV but not by a whole lot.
If you think that's fun, check out setting up a Citrix MetaFrame network. MS's weird-ass Terminal Services licensing scheme almost guarantees you'll be out of compliance unless you just write them an enormous check up-front. It's the most screwed up scheme I've ever seen.
Well it's not that hard to fix. (Score:4, Informative)
Re:Well it's not that hard to fix. (Score:5, Insightful)
(this of course assumes it's impossible to just get rid of the windows machines and they actually need cetralized authentication in the first place...)
Parent
Re:Well it's not that hard to fix. NDS != Evil. (Score:5, Informative)
I have no great love for Windows. Novell, I happen to like very much but it is cost prohibitive. But is NDS worth the money? Yes. Also, GroupWise is capable of driving Outlook properly, even better than my beloved OpenMail [RIP, now Samsung Contact - yeach, thanks Carly] was.
My experience since Novell 4.x (I've used it back in the bindery days as well) and NDS has been flawless. It supports DOS, WinALL, and anything else. It has native file sharing so it can appear as a Winderz box. The server is ugly as sin at the console, but it runs more reliably that one would ever imagine, I had several servers stay up for more than a year. The Novell client integration with Windows NT based operations systems is superior, supporting advanced network trashcans, robust undelete for idiots, and does interesting things like server side searches (as in, if you are looking for the word "cat" on a network file system, the server does the searching 'for you.'
Also, NDS is much more scaleable than ADS. It has the proper notion of root, it is possible to merge trunks together, if you've ever used ConsoleOne, you'll see more granularity on this directory and its objects than was ever dreamed possible, cleanly integrated and rather fast.
Is Novell run by intelligent business people? No. Are the products of incredible quality? Yes. Novell's image has been so heinously stained, with angry red color schemes, idiotic pictures of polyester clad fools running around on my console dancing or holding up red N's.
Novell needs to do only this: Change colors to blue or something, and rip out that licensing shit and start offering to replace ADS/Exchange with NDS/GroupWise for $100 bucks. All it costs them is a CD. It would cost Microsoft a lot of pain.
If you haven't given Novell a shot, please do,. You'll realize that the free stuff right now is primitive compared to NDS. Any other comments on good directory service implementations are welcome.
I just setup a Novell 6 server the other day to stay sharp with that stuff. Besides the fools in the marketing department over there, I was impressed with it. I would take a job working with Novell and Unix, but if someone wanted me to deal with Windows ADS or NT4 DS again, and not be open to Samba, I would probably not take the job or demand a premium.
Parent
Re:Well it's not that hard to fix. NDS != Evil. (Score:3, Interesting)
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
-----
AuthType Basic
AuthName "Secure_Site"
AuthNDSTree TREE_NAME
AuthNDSContext
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.
Re:Well it's not that hard to fix. NDS != Evil. (Score:3, Informative)
to do user auth against mysql as an apache module, works like above.
There's also http://www.giuseppetanzilli.it/mod_auth_pgsql/
Novell is playing attention to the good stuff
Re:Well it's not that hard to fix. OS X/NDS here (Score:4, Interesting)
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)
Parent
Have Win2k authenticate against LDAP instead (Score:3, Informative)
Will do that. I think in the end, I think the benefits of few less win2k servers to maintain/buy is worth the client install.
Re:Well it's not that hard to fix. (Score:3, Informative)
Beyond that, there are a large number of reasons. If you've never used Active Directory, then you don't understand the integration it offers that you can't find elsewhere easily.
AD is a Rube Goldberg hack of LDAP (Score:4, Informative)
LDAP user = a paragraph or two of logically arranged and named fields.
AD user = a page and a half of garble!
There's a reason MS has an AD "connector for LDAP" product (for a small fee).
AD might technically have the same modes of communication as LDAP but that's like saying just because I can use the same phone to call my Aunt and that friendly guy in Nigeria that they can and should talk to each other. (Okay, bad analogy, but I thought iwas funny.
So, to summarise for anyone who hasn't had the pleasure of attempting to integrate AD and LDAP, they ain't even close to compatible Jack!!
Parent
Using AD for authentication (Score:4, Funny)
Step 2: login using AD credentials
Step 3: There's no step 3! There's no step 3!
Re:Using AD for authentication (Score:5, Funny)
er, profit????
Parent
Re:Using AD for authentication (Score:3, Informative)
Re:Using AD for authentication (Score:3, Insightful)
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. Its really that simple. Folks need to stop complaining about MS and just either suck it up, or not use their tech. If its good, use it. If its not, don't - and don't complain.
OS X is more compatible with Windows than Windows is with OS X. Finito.
Cheers.
Re:Using AD for authentication (Score:4, Informative)
that is, create the NT user whenever you add a new LDAP user.
Have a OpenLDAP replica running on your Win2k box. Include a Perl trigger, that parses ldapadds and creates a local Win2k user whenever a new LDAP user gets added.
Perl can be used to synchronize the passwords as well, so you don't need Winbind.
checkout http://acctsync.sf.net/ [sf.net] For more info.
Parent
Hey, man. I only work here, you know? (Score:3, Interesting)
Winbind??? (Score:2, Interesting)
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? (Score:5, Interesting)
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
Re:Why not Samba? (Score:5, Informative)
Yes. It's unnecessary. Active Directory can expose an LDAP interface, and Mac OS X is an LDAP client. The only tricky part is synchronizing the schemas, and Apple's documentation describes how to do that. On paper, it looks really simple. Since I don't have any Windows servers, I can't say whether it's simple in practice or not. The submitter evidently thinks it isn't.
Parent
Active Directory is different than Active Desktop (Score:3, Offtopic)
Just ask MS to open the API (Score:2, Funny)
Oh wait they don't have to since this would involve Security, DRM, Authentication, Innovation, The Butterfly, etc...
MacOS X and linux (Score:2, Interesting)
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
Active Directory vs. SMB? (Score:3, Interesting)
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
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.
From O'Reilly Press (Score:5, Informative)
What is Active Directory? (Score:3, Insightful)
I also have it sharing folders out to the windows machines though it doesn't give out a listing of what's shared (probably for security reasons). You have to tell it what username, password and share you want to access.
What exactly are you trying to do?
Re:What is Active Directory? (Score:3, Interesting)
It essentially eliminates what you describe. AD is useful in multi-server networks or networks with many clients - it stores logins for all users, shares, permissions, printer definitions, etc etc.
Chances are your network is a little broadcast "workgroup". That works great until you have 4000 machines - at that point a workgroup-based network sucks ass and you need a server that just catalagoues the contents of the network. Thats the idea behind most directory services.
It relies on LDAP (Score:5, Informative)
Most likely, the configuration issues are with configuring the AD with the proper schema. When the AD is properly set up, then all you have to do is go into the Open Directory Assistant and create an LDAP service that is configured to use the Active Directory preset. Yes, it's a preset and so there is little or configuration on the OS X side. Once the LDAP service is created, then you select it as an authentication service (in the same utility) and you are done.
modified == *extended* (Score:5, Informative)
All they have done is provide a bridge and NetInfo schema such that current NetInfo account information can be published via LDAP directly from the NetInfo database. They're not the bad guys here.
Parent
Ummm...did you try Google? (Score:3, Informative)
Here is the link for the uniniated:
MacOSXwithActiveDirectory.pdf [apple.com]
Re:Ummm...did you try Google? (Score:5, Informative)
I can't seem to find a similar doc on Jaguar. Maybe because Apple has not released it yet?
Parent
AD documentation for 10.2 (Score:5, Informative)
Active Directory for Mac OS X Server v10.1: Learn how to integrate Mac OS X Server v10.1 with Microsoft Active Directory. (v10.2 customer, refer to the Administrators Guide for Active Directory integration documentation.)
The Mac OS X Server 10.2 Admin Guide is available from:
http://docs.info.apple.com/article.html?artnum=12
Particularly, see:
Chapter 2: Directory Services (p.65)
Using an Active Directory server (p.104)
Parent
Re:Ummm...did you try Google? (Score:3)
Yes, that PDF was documentation for OS X 10.1. In 10.1 the clients had to connect to an OS X 10.1 Server to authenticate centrally. The 10.1 Server acted as a gateway which connected to Active Directory. No gateway, no authentication.
OS X 10.2 is not supposed to require and OS X Server for AD authentication, it's supposed to be able to talk to AD by itself. I think this is due to the addition of LDAPv3. Previous I think OS X only had LDAPv2.
I haven't had a chance to try it but I've had a look at the documentation. It *may* be possible to follow the instructions for configuring the AD and for configuring the client with only a minor modification. Instead of putting in the address of an OS X Server (one of the steps), you would put in the address of an Active Directory Domain Controller.
However other people have posted that they haven't been able to get it to work, even with the assistance of Apple engineers. Not good.
Re:Ummm...did you try Google? (Score:3, Funny)
How are you supposed to save Xmas if you have to read a manual first!
LDAP support != AD integration (Score:4, Informative)
Active Directory (at least the MS implementation) is like a network-level "registry". It holds everything from integrated DNS records, to DHCP server authorization, users, permissions, replication controls and information....you get the idea.
To participate in most of this, you need to have client side stuff that can take advantage of all of this. OK, you get samba authentication without needing LDAP support on OS X, but who cares...that isn't enough for "seemless" integration.
Can you add users to OS X and have them appear in Active directory?....I don't think so.
Can you get your DHCP server (on OS X) to authenticate itself in Active Directory?...probably not.
Can you get user lists and permissions to replicate into OS X's user list? Maybe...but i'm still not sure about that.
Lastly...can you get a user to log into OS X and have OS X process login scripts replicated to domain controllers? Doubtful...most of the windows login scripts don't apply to the Unix world.
I may be wrong on this stuff. My experience with OS X has been a handful of workstations connecting to a windows file server via samba. It seems that the platforms are too far apart to get this "seemless" integration.
It appears the best you can do is simple user authentication....it might be worth it if the OS X server can get it's user list from the Active Directory machines. Does anyone know if this is possible? I'd love it if a Linux distribution could do that so I don't have to maintain two sets of user lists.
-ted
Re:LDAP support != AD integration (Score:5, Insightful)
Can you add users to OS X and have them appear in Active directory?
The point of a central directory service is that you create the user records in one place (using the native tools) and all systems can authenticate against them. Adding users to your Mac OS X machine doesn't make sense under centralized directory services. With the correct administrative user login, it is possible for Workgroup Manager to edit user records in an LDAP server using LDAP v3 mechanisms.
Can you get your DHCP server (on OS X) to authenticate itself in Active Directory?
DHCP does not by nature authenticate. DHCP servers can send out additional vendor-specific DCHP packets -- Apple's implementation does this to tell Mac OS X clients where to look for directory services -- but they do not authenticate directly to DHCP. These additional records are ignored by systems that don't understand them. Look into the Mac OS X Server documentation and the
Can you get user lists and permissions to replicate into OS X's user list?
The point of central directory services is to NOT have everything replicate into client systems!
Lastly...can you get a user to log into OS X and have OS X process login scripts replicated to domain controllers? Doubtful...most of the windows login scripts don't apply to the Unix world.
You've answered your own question here -- the Windows-based login scripts do not make sense and would not run under Mac OS X. Mac OS X has its own ways of setting up scripts to be run on boot and on login, as well as automatically mounting share points.
Scripts can be run from the
Parent
Re:DHCP does not by nature authenticate??? (Score:3, Insightful)
And, as you pointed out, any other device plugged into the network that can broadcast DHCP can cause the same chaos. Mac OS X makes it so that regular users without admin privileges cannot turn on DHCP, either on Mac OS X or Mac OS X Server. Keep non-technical users as non-admin users and you will never have the problem of DHCP interference.
I guess what I want is Linux or OS X to act like an Active Directory DC....to do all the things that Microsoft's AD-DC's do.
This gets to the core of your problems -- you have a VERY Microsoft-centric view of the world. Forcing authentication against a Microsoft-specific non-standard server protocol just because that's the way Microsoft does it is a really poor way of getting interoperability. Other systems have other ways of handling directory services and security -- look at them in their native environments and work with them, don't treat every problem as a nail just because all you have right now is a hammer.
--Paul
Google knows all (Score:3, Informative)
Since you said in your submission, "Documentation? HA! No sign of it anywhere on Apple's site," it seems clear that you haven't read this document yet. Give it a try. As I wrote elsewhere, I don't have any Windows servers, but from reading the instructions, it looks like it will be very easy for you to set this up just the way you want it.
The problem is probably not with Apple (Score:3, Insightful)
My primary complaint against SMB is that it doesn't really work all that well. When I tried to look at the list of computers in Network Neighborhood, I often saw only a partial list (some computers that I knew were connected did not show up). The only way I could connect to these was by specifying their IP address. Other times, I could not access them at all (even though in some cases they could still access my machine!). I switched to Linux a while ago, and I have had similar results using SAMBA.
This leads me to believe that the fault for bad Windows Network performance lies not in the implementation (whether SMB on Windows, SAMBA on Linux, or the Apple implementation) but in the protocol itself.
Get a server. (Score:5, Informative)
It sounds like your real problem is getting AD to play nice with LDAP clients. The reason that Microsoft clients integrate "seamlessly" with AD is that they use some funky proprietary directory protocol, whereas everything else (Linux, Mac, etc.) speaks straight LDAP. I've found that 10.2 has pretty darn good LDAP integration, but getting it to work with Microsoft takes some accomodation on the AD side.
Remember that Macs use open protocols and tools for their Windows integration. Samba is used for the SMB stuff and LDAP for directories. Any time you're using proprietary MS protocols, you're going to run into problems. You'll run into the same situation with Linux, Novell, or anything non-MS. If your mandate is to make the Macs behave exactly like Windows, then they're setting you up for failure
That being said, you can really help yourself out by getting a 10.2 server to act as a bridge. Apple's OpenLDAP is still fairly young, but it really simplifies AD integration. With your modest requirements, you probably use an old iMac. The server software for 10.2 server is pretty cheap with educational discounts ($250 for 10 clients, $500 for unlimited), and it doesn't require much of a box. I'm using an iMac server to get a 20 station lab on AD and it works pretty well. You get some really cool deployment and workstation management tools, too. ;)
I hear you about the documentation, though. I don't mind so much, because I like tinkering with things and Apple's stuff is fairly intuitive. However, when you're just starting out, Apple's "Why would you need a manual?" attitude gets pretty annoying.
It Doesn't Work, Yet. I've Tried. (Score:5, Interesting)
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. (Score:3, Interesting)
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.
What we found... (Score:3, Informative)
WTF? I have to buy consulting? They won't even *help* you through it over the phone, they direct you to the discussion forums. Basically my point is that Apple won't even support vanilla test-only installs, let alone ones in production.
The way it basically works is that Apple's own LDAP flavor (OpenDirectory) only works with Apple clients. *But* you can make some additions to the Win2k/AD Schema (not that scary) and make it so Apple's OpenDirectory can read attributes (users and shares) from AD, letting AD users login locally to a mac. Great stuff, yet to see it work.
The documentation sends you all over the whitepaper, looking for info on how to do this and that, and leaves out crucial steps (enabling LDAPv2 in AD, for example, as well as enabling LDAPv2 write access).
I'm no apple basher, but at the very least they should stop saying it's easy.
A little more to the story (Score:5, Informative)
My understand of the OS X client is that it doesn't contain true Active Directory client support. Instead, it relies on the fact that most AD installations are in mixed-mode where they still accept old client logins. In fact, only the bleeding edge versions of Samba actually support true Active Directory client login as it erquires some pretty obscure protocols that only recently have been understood (LDAP over UDP and other various nonsense).
Chances are, your network is in native-mode. That would kill your chances of using the native OS X CIFS clients (although Samba should allow you to access network resources if you use a beta 3.0 version).
Re:Hypocrites (Score:3, Insightful)
Your Samba configuration is wrong (Score:3, Informative)
This number is how MS machines determine who is the Primary Domain Controller, basically the one with the highest OS level gets it, unless things are specifically configured otherwise. IIRC, Windows NT 4 has an OS level in the low 30s. Newer versions of Windows have higher OS levels, and server versions have higher levels than workstation or desktop versions.
So, all you have to do is use SWAT, or otherwise edit smb.conf, and set your OS level to some low number, like 1.
This site [uoregon.edu] is a good introduction with lots of useful tips. If you really need to know Samba, though, I highly recomend this book [bookpool.com].
Re:RTFM (Score:3, Funny)
Wow. Another RTFM post. Brilliant. So, I take it you read the actual Ask Slashdot question then, right? The part where he says he knows how to get it working, and wants to know if it has been this hard for everyone else to do so as well? Did ya read that part? Cause I don't think that ya did.
For reference:
"...It is possible, but not without a good deal of nightmarish configuration issues...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." So that was the part where he says he knows how to do it. Now this is the exciting part... the ACTUAL question...
"...I was wondering who else out there is having this problem, and what they have done to solve it." Cool, huh? Reading story good! Reflex comments BAD! REFLEX BAD!
Now, you did find documentation on Apple's site so that's gotta be worth some points. +1 Informative to you. Of course, that's not really the point of his Ask Slashdot, so you get a +1 Moron because you can't read and a +3 Asshole because you've used this thread as a vehicle to vent your frustrations at the world. Your Karma is now -1 Idiot. Congratulations.
Now, for anyone else that feels inclined to add RTFM to this discussion, save your breath. We don't care. Post something useful, and if you're not willing to add your name to it, maybe that tells you a little bit about the message you're posting.
Thank god I'm not a moderator or my Dogma would crap on your Karma