Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Networking (Apple) Businesses Apple Hardware

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

Posted by Cliff 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.

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

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

Comments Filter:

  • Title != message (Score:4, Informative)

    by Anonymous Coward on Tuesday November 05, 2002 @01:59PM (#4600760)
    Active desktop and Active directory are *slightly* different...

    • How to do it with OS X 10.2 (Score:5, Informative)

      by Anonymous Coward on Tuesday November 05, 2002 @04:05PM (#4601948)
      You will need 10.2.

      Browse to /Applications/Utilities, select Directory access. Select LDAPv3, click Configure, drop down the show options button, hit 'new', type a friendly name for your AD server, slap in its name or IP, Select Active Directory from the LDAP Mappings, use SSL if you want, fart around with the other options if you need to, OK everything, go back to Directory Access, Select Custom Path from the Search Drop Down, hit 'add', select '/LDAPv3/Your Friendly name'.

      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

  • Well, (Score:3, Insightful)

    by jcrash ( 516507 ) on Tuesday November 05, 2002 @02:01PM (#4600790)
    It isn't exactly in Microsoft's best interest to make this easy for them is it?

    • All they lose out on, is the OS License. Which when purchased from a Dell, et al, isn't that significant. When a Mac gets roped into the AD network seamlessly, they still get revenue from a copy of Office so the user can share docs with other users (LOTS more profitable than Windows). Plus a few more CAL's as well, for the file server(s) as well as the exchange server(s). All in all, it's still a good revenue stream for MS.
      • Unless you have Enterprise Licensing that is. As soon as you install Office for Mac, you have to pay them for an OS license as well. Check the fine print.

        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.
    • actually why would MS care, you have to pay the per seat liscense for the AD servers regardless of client platform. So what if they lose an OEM OS sale, they still get you per seat and probably for office too.

  • Well it's not that hard to fix. (Score:4, Informative)

    by miffo.swe ( 547642 ) <daniel...hedblom@@@gmail...com> on Tuesday November 05, 2002 @02:03PM (#4600814) Homepage Journal
    Get rid of that stupid AD and install a real catalogue system like LDAP or NDS. Active Directory is made for Windows and nothing but windows. Making anything else to work with it is very hard and not worth it. What on earth do you need from AD that cannot be solved otherwise? If its just a matter of a few machines there shoudnt be any significant gain in ease of admin in AD. If there are plenty then you should install a MAC server. Microsoft does not and will never play nice with anything else but Microsoft.

    • Re:Well it's not that hard to fix. (Score:5, Insightful)

      by Telastyn ( 206146 ) on Tuesday November 05, 2002 @02:12PM (#4600900)
      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.

      (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...)

      • Re:Well it's not that hard to fix. NDS != Evil. (Score:5, Informative)

        by Zeio ( 325157 ) on Tuesday November 05, 2002 @02:56PM (#4601261)
        I beg to differ about NDS on Windows ever being a problem.

        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.
        • 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.
          • As a side note check out mod_auth_mysql - http://www.diegonet.com/support/mod_auth_mysql.sht ml
            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)

        by Havokmon ( 89874 ) <rick&havokmon,com> on Tuesday November 05, 2002 @03:08PM (#4601407) Homepage Journal
        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)

      • http://pgina.cs.plu.edu/ [plu.edu]

        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.

    • Sigh. This may not be an option. Ripping out a directory service and replacing it is non-trivial. Getting MAC clients to work with AD may be a pain, but you seem rather blase about switching directory services. It's a shame that posts saying, "Rip it out, dipshit. Why did you install that shit anyway?" aren't actually helpful to people with real world problems.

      And, in fact, I'd suggest you audition NIS on Windows (yes, you heard me right). Services for UNIX v3.0 includes NIS (and NFS) server which integrates with Active Directory, so you can have NIS clients managed by the AD infrastructure. It costs $99, and also gives you a nice UNIX shell that you can use to tool around your AD server and a bunch of other goodies. (Having said that I don't anything about OS X, so I don't know how well it plays with NIS, but it's an avenue worth a look.)

    • What on earth do you need from AD that cannot be solved otherwise?
      Group Policy [microsoft.com]. If there's one thing that is important to an organization with many computers that require support, it's group policy.

      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.

  • Using AD for authentication (Score:4, Funny)

    by gruntvald ( 22203 ) on Tuesday November 05, 2002 @02:04PM (#4600818) Homepage Journal
    Step 1: plug into the network

    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)

      by Bob McCown ( 8411 ) on Tuesday November 05, 2002 @02:08PM (#4600863)
      Step 3: There's no step 3! There's no step 3!

      er, profit????

    • Precisely. It should really be this easy. OS X has a Directory Services manager where you can add the AD server in - LDAP compatibility will need to be enabled, obviously. At that point, you have the login. Setting up home-dirs might be a tad more tricky, but maybe not. I don't have an AD server here to mess with, but it really shouldn't be too difficult, as long as the 'standards compliant' features of AD are enabled.

      Cheers.
      • Actually, we have AD running, along with a bunch of OS X clients. We even had an Apple engineer here last week, and he couldn't figure out how to get the auth to handle such things as creating user dirs. It's a large, ugly mess.
        • Creating user dirs is a tricky problem. Samba w/ winbind and the PAM auth module is pretty difficult to setup for that, as well.

          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)

            by Kunta Kinte ( 323399 ) on Tuesday November 05, 2002 @03:28PM (#4601592) Journal
            It's easy if you do it the other way around.

            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.

          • 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?

  • Winbind??? (Score:2, Interesting)

    by 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? (Score:5, Interesting)

    by bdowne01 ( 30824 ) on Tuesday November 05, 2002 @02:06PM (#4600843) Homepage Journal
    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 :)

    • Re:Why not Samba? (Score:5, Informative)

      by Twirlip of the Mists ( 615030 ) <twirlipofthemists@yahoo.com> on Tuesday November 05, 2002 @02:30PM (#4601070)
      Any reason not to try?

      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.
      • Well that sounds like anything touched by Microsoft. "On paper, it looks really simple. " but then you get to actual implementation it is anything but simple. I guess that is why I have a job though =)

  • Active Directory is different than Active Desktop (Score:3, Offtopic)

    by Sycraft-fu ( 314770 ) on Tuesday November 05, 2002 @02:07PM (#4600846)
    Active Directory is Microsoft's enterprise X.500-like security and authentication scheme. You set it up on a network of Windows servers and the clients all authenticate with those. Active Desktop is putting a webpage on your desktop.

  • Just ask MS to open the API (Score:2, Funny)

    by Anonymous Coward
    Couldn't we just ask nicely for Microsoft to open up the APIs for Active Directory?
    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)

    by rkt ( 9943 )
    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
    • This is actually quite easy, all of my Solaris and Linux machines autheticate to AD, just fine. Never tried with OS X, but it sounds like it might be a bit easier, since Apple has a somewhat vested interest in making it work. I use the pam_ldap and nss_ldap modules from padl.com. Follow the newsgroup thread here: http://www.netsys.com/nssldap/2002/02/msg00031.htm l and the "cookbook" here: http://jaxen.ratisle.net/~jj/nss_ldap-AD_Integrati on_how-to.html
      • Just to clarify something, although Apple have included PAM in OS X 10.2, it's kind of useless, as /etc/pam.d/login isn't actually consulted at the login window. yeah. brain dead and bloody annoying.
    • 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.

    • I've written code that authenticates against active directory just fine. Active directory is, after all, accessible through standard LDAP protocol.
  • 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.

  • From O'Reilly Press (Score:5, Informative)

    by wayn3 ( 147985 ) on Tuesday November 05, 2002 @02:10PM (#4600875)
    Have you tried this [oreilly.com]?
    • I read that sample chapter. It seems useless in relation to the topic. They list appletalk and netinfo as the legacy services, and then proceed to go into great detail on how to setup netinfo, not discussing any of the others at all... Why would we want to use the legacy directory service?
      • I play it cool, and dig all jive
        That's the reason I stay alive ...

        Cool to find another Hughes fan on Slashdot.

        As for that book, it spends too much time on basic
        unix stuff like what a here document is. As a friend
        of mine quipped, it should be called "Unix for Mac
        OS X Users".

  • What is Active Directory? (Score:3, Insightful)

    by Fugly ( 118668 ) on Tuesday November 05, 2002 @02:11PM (#4600891) Homepage
    I'm not sure what active directory is but I do know that using Jaguar, my machine can browse my windows network and connect to any shared folders very easily.

    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?
  • 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

  • It relies on LDAP (Score:5, Informative)

    by fordgj ( 522469 ) on Tuesday November 05, 2002 @02:12PM (#4600899)
    10.2 uses a new architecture called Open Directory which is released as open source (yes, the apple license, of course). Open Directory is what allows 10.2 to work with Active Directory. How does it do this? LDAP.

    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.

  • Ummm...did you try Google? (Score:3, Informative)

    by krove ( 623161 ) on Tuesday November 05, 2002 @02:16PM (#4600934) Homepage
    Apparently not. By entering "Active Directory under OS X" the very first entry is a PDF by Apple with instructions on page 35 on how to setup clients to authenticate to the active directory domain controller.

    Here is the link for the uniniated:
    MacOSXwithActiveDirectory.pdf [apple.com]

    • Re:Ummm...did you try Google? (Score:5, Informative)

      by Magycian ( 121354 ) on Tuesday November 05, 2002 @02:21PM (#4600968)
      Ummm That link is for 10.1. VERY different animal.
      I can't seem to find a similar doc on Jaguar. Maybe because Apple has not released it yet?
    • Hey...you mean we have to read a manual to get this stuff to work? But I want it now!

      Joking aside, he still has a point about needing a machine running OS X Server. The ad makes it out that having a Jaguar client will just work, without the need for a third computer...
    • There's a lot of redundancy in the comments for this article but here's something I don't think anyone has mentioned.

      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.
  • We are still in mixed mode and using connetix ( what a piece of crap product ) on a 9x mac, to authenticate to the NT side.

    I worry that it will die when we go native in teh spring. And no upgrade to 10x in sight due to application issues. fun fun wish us luck !

    • This may be OT, but mixed-mode doesn't have anything to do with how your clients authenticate. It has to do with what types of domain controllers you have. If you have nothing but Win2k DCs, you can run in native mode.

      I'm running my ActiveDirectory in native mode and I have plenty of "downlevel" clients authenticating using the old NTLM protocols.

      • We still have NT BDC's spread out. Will be months before all are converted to win2k.

        Whhen we go native it DOES effect how clients authenticate. Does it matter, perhaps not but it does effect things.

        Actually, mixed mode isnt 100% compatible as we have already expierenced problems with some local software. Though so far the mac hasnt puked beacuse of it.

  • I'm glad it was Active Directory not Desktop (Score:2, Funny)

    by Anonymous Coward

    For a second I thought they were trying to make a rotten apple

    Any idea how to take Active Desktop out of windows?

  • You know, slashdot really isn't as good of a search engine as Google.

    1) Go to google.com
    2) search for "active directory mac os x"
    3) click the third result.
    4) prof- nah.

    Or you can click this link:
    Integrating Mac OS X with Active Directory [akamai.net]
  • A quick google returns this as the first reference: MacOSXwithActiveDirectory.pdf [apple.com].

    • Had you actually *read* the document you linked to, rather than googling for forty seconds and then patting yourself on the back, you might have found that this is the sole reference to Active Directory:

      LDAPv3
      This is a newer version of LDAP, which Mac OS X fully supports (read-write). This is the same version of LDAP used by Microsoft's Active Directory and Novell's NDS.
      The poster's problems are a very real issue and are well-deserving of a public question on Slashdot.
  • Well, after spending nearly 3 minutes looking, I found this handy PDF [apple.com], which tells you to configure the ldap thingy in AD (however the hell you do that). There also seems to be an Active Directory schema option in Directory Access when configuring LDAP servers.

    No, I've not tried it as I don't have anything which talks Active[sic] Directory, so YMMV.

  • A quick searc for Active Directory on the Apple website turns up these results:

    this [apple.com]

    this [apple.com] and the PDF linked to on that page can be found here [akamai.net]

    There ae also links on Apple's site to third pary sites which deal specificaly with Mac - PC network integration.
    • That's for Open Directory - essentially Apple's Active Directory for OS X Server. He is not wanting to set up an OS X server on his network, but have his OS X clients connect to his Windows 2000 server using the active directory.

      OS X 10.2+ has a gui interface for Samba - this is your best bet for connecting clients to your server. It does not authenticate them through Active Directory, but more the method that a Windows 98 machine will connect to your server.

      Active Directory connectivity is "closed source" and I'm sure much coveted by Microsoft. Chances are, you won't be doing something like that with ease.

  • Comment removed (Score:4, Informative)

    by account_deleted ( 4530225 ) on Tuesday November 05, 2002 @02:25PM (#4601014)
    Comment removed based on user account deletion

    • Re:LDAP support != AD integration (Score:5, Insightful)

      by plsuh ( 129598 ) <plsuh@noSPaM.goodeast.com> on Tuesday November 05, 2002 @03:21PM (#4601517) Homepage
      This list consists of items that are irrelevant or unnecessary:

      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 /Applications/Utilities/Directory Access application to see the options.

      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! :-O When a Mac OS X system that utilizes LDAP directory services for group information it asks the LDAP server, not its own local NetInfo database or BSD-style config files.

      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 /etc/rc scripts or from the /Library/StartupItems folder. On login, there are a variety of options detailed in Apple's docs [apple.com].

      • Comment removed based on user account deletion
        • DHCP authentication as you described is a Microsoft extension to the standard and is not a part of any RFC that I am aware of. In point of fact, no non-Microsoft DHCP server implements this protocol and as a result, any other device that wants to broadcast DHCP packets can do so. The DHCP server on Mac OS X is really just a slightly modified version of the ISC reference implementation of bootpd. By design, you can set up the DHCP server on Mac OS X to respond to directory services request packets but not other types, such as IP address allocation requests, so that Mac OS X machines can pick up directory services information via DHCP and still interoperate with existing DHCP servers.

          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

  • AD and Unix integration (Score:2, Informative)

    by Anonymous Coward
    A disclaimer first: I haven't tried to do this on MacOS X, but just did the same for Linux; you can do it on any unix that supports PAM for authentication.

    It is certainly possible, however I wouldn't call this integration a "seemless" one (I didn't use samba for that).

    You can extend AD schema to support unix by using AD4Unix package [css-solutions.ca].
    After that you need to install nss_ldap [padl.com] and pam_ldap [padl.com]. A good starting point on how to configure these two can be found at Security Focus [securityfocus.com]. You may want to use Kerberos for authentication, as pam_ldap transmits username and password over the network (although with SSL support this data will be encrypted).

    Hope this helps,
    AC
    • Another alternative to AD4Unix (if you don't mind giving MS a little extra money ;) is to purchase Microsoft's Service's for Unix (~$120), which gives you the AD schema extensions and adds the support into the AD user admin screens. AD4Unix is a great product, but I got a little nervous about modifing the AD schema and having some future SP come along and blow it away. At least this way, hopefully, future SP's will see SFU installed and leave it alone. ;) Plus you get some neat extra's like an NFS server for W2K and an NIS server (which you won't need, if you integrate with AD).

  • Mac OS X in Labs (Score:2, Informative)

    by rigmort ( 584960 )
    Check out macosxlabs.org. They've got TONS of good info. I'm facing a deployment of OS X this spring and I'm not looking forward to it. Also, read Apple's white paper entitled "Mac OS X with Active Directory" in PDF format at:

    http://a1584.g.akamai.net/7/1584/51/7f99c60f0c08bf /www.apple.com/macosx/server/pdf/MacOSXwithActiveD irectory.pdf

  • As I mentioned earlier, we have Active Directory, as well as a Jag server. We had an Apple engineer here for two days, and not even he was able to get AD-style login-auth to work - the basics like proper mapping and creation of home dirs on network instead of local host and all that. It looks like Apple still has quite a bit of work to do here. On the bright side, I use Cmd-K to logon to any of the network shares, and the perms are correctly handled. But we are looking for a logon screen for OS X that uses our AD for auth, and so far nyet.
  • Probable webpage on Microsoft.com:

    "This link will let you download instructions on how to use Active Directory for 3rd part OS'es, such as MacOS. By clicking on this link, you agree to the following:

    1) I will not redistribute this document
    2) I will hyperlink to this document, bypassing this EULA.
    3) I will not use the information contained wherein to bypass Windows security settings by authenticating any 3rd part OS via Active Directory ( DMCA )"

  • Google knows all (Score:3, Informative)

    by Twirlip of the Mists ( 615030 ) <twirlipofthemists@yahoo.com> on Tuesday November 05, 2002 @02:33PM (#4601099)
    Go to Google. Type "apple.com active.directory" in the search box, and mind the periods. The very first result is a PDF from Apple's site entitled "Integrating Mac OS X With Active Directory [apple.com]." (Just to be clear, that link is directly to the PDF, so don't click unless you're ready to download.) In it you can find step-by-step instructions for setting up both the clients (simple) and the server (complex, but only has to be done once).

    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.
  • Getting OS X working with AD can be done, but you need to do it with Samba. Read the Samba documentation, learn to use Samba, and you should have no problem getting your OS X systems to work with AD. This will require research, effort, and scariest of all, it will require editing text files and maybe even working with the command line, but with some time even a Mac user should figure it out.
  • I'm an IT admin, and we have Win2k running AD on our server, and we have 10+ Mac clients running OS 10.2. The key is, make sure the user accounts and the user alias on the domain controller are the same..meaning, if your user account is named joe smith, make sure the alias is the same. Hope that helps.

  • The problem is probably not with Apple (Score:3, Insightful)

    by igotmybfg ( 525391 ) on Tuesday November 05, 2002 @02:45PM (#4601188) Homepage
    Windows Networking is based on the SMB protocol. I have been using it for years, first in my home network, then at my university. I have had lukewarm results, at best.

    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.

    • How is this modded as "Interesting"? Is it becuase it bashes a protocol used by MS? Hell, the guy doesn't even know what he's talking about.

      The name resolution used while browsing the network is NetBIOS. SMB/CIFS is the protocol used to "talk" to the server once you have it located.

      It sounds like this guy had machines on seperate subnets and expected to find them by using a protcol that relies on broadcasts. That's what WINS is for.

      Anyway, I will be one happy camper when MS drops support completely for NetBIOS and relies solely on DNS & LDAP. Dynamic DNS is one step towards supporting that reality.
  • Based on Apple's adverts of "seamless" we told people they'd be able to browse my organization's full list of local windows servers from MacOsX10.2's [Connect to Server] command. As stated in the linked article, it quickly became clear that browsing using active directory only works for severs on the local subnet. Fortunately, if you already know the name or address of the machine you're trying to connect to, you can log on directly by entering: . So far, this has worked just fine on non-local subnets.

    So for my org, it's a mixed review. It's a long way from "seamless", but it's a LOT better connectivity than MacOS has ever had before. If Apple had advertised what they actually delivered ("Now you can log onto a windows server"), we'd be thrilled.
  • 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.
  • Have you ever tried to get "Mac People"and "Windows People" to integrate. They run on the same hardware yet seem totally incompatible.

  • http://acctsync.sf.net [sf.net] - It's difficult to deploy, but it works.

    There are other such products, like PSych and NDS, which may be easier to work with.

    Using this ensures that you don't have to rely on a Win2k LDAP network for authentication services ( read Win2k license for every AD replica, additional CALs )

    But you can alternatively deploy an OpenLDAP set of replicas and have all your services/computers authenticate against them ( read free, their don't care how many you deploy or what you put into them ).

    Microsoft not having Win2k play nice with others is having the beneficial side-effect of increasing their Win2k sales.

    Hmmm... Hey! You think that was their plan to begin with?

  • Get a server. (Score:5, Informative)

    by megaduck ( 250895 ) <dvarvel@hotmaiCOLAl.com minus caffeine> on Tuesday November 05, 2002 @03:02PM (#4601326) Journal

    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)

    by Spencerian ( 465343 ) on Tuesday November 05, 2002 @03:20PM (#4601507) Homepage Journal
    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.
    • ...when people complain about Apple not documenting when it is Microsoft's non-standard nonsense that caused the problem in the first place.
    • I'd just like to back up everything that you are saying. I have been working with one of my clients to get OSX-AD integration set up for several months now, with no luck. First we started with 10.1, and we have now moved on to Jaguar. Although I am not an Apple expert, we are working with the top Apple support company in our city, which frightenlingly is also the only one that is supporting OS X in large environments yet (this is in a city of 3 million). We have also had two engineers from Apple come and assist us, and we've had no luck. My client was supposed to be a showcase for Apple, to show how great it integrates with Windows and how it can be used by large corporations and institutions, so Apple definately has an interest in making this work. But still, no luck. As a matter of fact, the IT department at my client sent me an email earlier today saying that they would like to end the project, since it is going nowhere. It is a great disappointment to me, since I would really love to make this work, but I can't blame them at all. It seems like the big problem is that no one really has any idea how to set this up correctly. We've spoken with places where they have been able to make it work, but either they haven't actually made all of it work like it should, or they have it setup in a convoluted manner that we can't emulate on a large scale. Apple's engineers have been little help. Although they know a lot about Macs in general, it seems like they really don't know what they are talking about when it comes to LDAP and the AD integration. I really get the feeling that they just think that it SHOULD work, with minimal effort, and when it doesn't they just fall apart. I am considered to be an LDAP and NDS expert, so I have a good knowledge of how this should work, but unfortunately it just doesn't. It's been a huge dissapointment. The worst part is, I had several other clients that were ready to implement this, but I have had to inform them that our pilot testing isn't working, so we won't be implementing it any time soon. I guess I'll just hope that they get it worked out eventually, and maybe try it again later.
      • 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.
  • ... 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 ;)

  • Uh, what the hell is the purpose of this article? Shouldn't this be under "Ask Slashdot" or perhaps "Senseless Ranting"?

  • What we found... (Score:3, Informative)

    by Null_Packet ( 15946 ) <<ten.rehcsod> <ta> <tekcapllun>> on Tuesday November 05, 2002 @03:38PM (#4601686)
    I work for a company that looked into it recently. We bought an XServe, read the docs, and when I tried to assemble it in a test environment (Fresh AD infrastructure, own address space, etc) I ran into problem after problem. Finally when all the people at the Apple Support Forums (http://discussions.info.apple.com/) we got an error. So I called apple support. Would they help? They said no. Would Apple Pro support help? They said no. They said "We can get you in touch with Apple Consulting Services to help you get it working."

    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.

  • Oh god (Score:2)

    by 0xA ( 71424 )
    Uhh, we're talking about extending an LDAP (MS AD) schema and maybe setting up Samba here. Not exactly friggin rocket science. I would suggest you read up some on LDAP and SMB, once you understand the basics of this stuff all will become clear to you. I would hardly call what is going on here a nightmare.

    Keep in mind that nothing you are doing here would be at all new to someone who has used LDAP, or MS AD, in a Linux + Windows or Sun + Windows environment. Keep in mind that your shiny Mac is a Unix based machine and eperience and tools from other platforms will apply. Get off your ass and spend 5 minutes with google.

    Is is possible you are just stupid? I read the site you linked to, most of these people are definately stupid. You have a MCSE right?

  • A little more to the story (Score:5, Informative)

    by lkaos ( 187507 ) <{sw.yeknomedoc} {ta} {ynohtna}> on Tuesday November 05, 2002 @03:51PM (#4601792) Homepage Journal
    Having worked on Active Directory interoperability in Linux along with giving a presentation at the recent CIFS conference on the topic, I can speak to this issue with a certain degree of confidence.

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

Slashdot Top Deals

"How to make a million dollars: First, get a million dollars." -- Steve Martin

Close