vlr.netlify.app

1. Mac Os X Active Directory
2. Active Directory For Mac
3. Active Client For Mac Downloads

To expand on Santosh Bhandarkar's reply, Likewise Open is extremely easy to use. Depending on the client OS and how you approach it, it could take a bit of researching or as easy as clicking through a few items. Jesus Vigo covers five common Active Directory connectivity issues affecting OS X and offers solutions to help resolve them. Between the client (OS X) and the directory server (AD). Learn how to use DCE/RPC and the Active Directory Certificate profile payload to request a certificate. Bind the OS X Mountain Lion or later client to AD. You can use a profile, GUI on client, or CLI on client to bind the client. Request a certificate from a Microsoft Certificate Authority. More ways to shop: Visit an Apple Store. When you bind a Mac OS X client computer to Active Directory, you use or create a computer object for Mac OS X. Just like user objects, computer objects are used for identification, authentication, and authorization. Add a Mac OS X computer to Active Directory For Further Study Given Microsoft’s historically contentious relationship with Apple, it never ceases to amaze me at the relatively high degree of interoperability that does exist between a Mac OS X workstation and an Active Directory Domain Services (AD DS) domain.

I have more than 50 Macs on the network and I think it's time to put some controls in place so I'm scouting for ways to integrate the Mac OS X clients into Active Directory. The primary objective is to enforce GPOs from the AD to the Mac OS X clients. I'm thinking of the following solutions:

• Use Mac OS X Server's Directory Service with AD
• Use a third-party solution like Centrify's DirectControl or Thursby's ADmitMac

Which of the solutions do you think is the best way to go?

FrancisVFrancisV

3 Answers

It depends on whether or not you want to install 3rd party software on your AD controllers. If you go with Thursby or Centrify, you will have to do that to get GPO. This adds the necessary attributes to your AD schema to make it more OS X aware. I'm not sure if it'd include everything you'd want, so you'd have to ask the vendor.

If you don't (a lot of people don't), you'll need an OS X Server and set up a golden triangle configuration. You'd make the OS X server an OD Master (standalone), join it to AD, then use MCX to apply 'GPO' to the computer object in AD. Then you'd join the computer itself to AD & OD. What it doesn't get from AD, it'd get from OD (if you configured it correctly). Things like password policy work with AD by default, with some minor caveats (reminders of expiration). Things like accessing System Preferences would be managed in OD. If you go the golden triangle route, you should consider getting two servers for master & replica. This doesn't require modifying or installing anything in AD that's not already there.

The only downside to the golden triangle setup is Lion is around the corner, and I'm really not sure if it'll continue to support this type of thing. I'm not sure how much longer you'll be able to buy Snow Leopard Server. Also, you can no longer get Apple's Xserve brand new.. you're stuck with a Mac Pro or Mac Mini.

churndchurnd

In addition to the options @churnd listed, you can also extend your AD schema to directly support Mac-style managed preferences. Apple has white papers on how to extend the schema to support OS X v10.5 and OS X v10.6 (the differences aren't very important -- the 10.5 instructions include a bunch of object classes and attributes that nobody used and were removed/obsoleted in 10.6; the 10.6 instructions include a new computer attribute that you don't need either. tl;dr either set of instructions work for either OS X version). They also have a video showing the extension process.

I have no idea how well the resulting schema extensions will work with OS X 10.7 (Lion).

Some notes and gotchas on the process:

• You need an OS X server set up so you can diff its schema against your AD domain.
• Run the schema extension on a test system first, and make sure it works right.
• In the 10.5 instructions, the settings for apple-computer-list at the top of page 7 are wrong (they list apple-computer-list-group twice), as is the following text (it lists apple-generateduid twice); you should follow the list at the bottom of page 7 instead.
• The UI in AD Schema Analyzer is very confusing. Each class has two boxes next to it: one to hide (minus sign) or show (plus sign) related attributes, and another to exclude (blank) or include (heavy plus) it in the export. Related attributes have one box, which can implicitly include (plus on gray background) or explicitly exclude (heavy X) it from the export. You have to click to select the classes to include, and then under each of those, click to exclude the attributes that you don't want.
• If you cut-and-paste any of the LDIF from the white paper (e.g. the auxiliaryClass and possSuperiors stuff) from the PDF, you may wind up with spaces at the beginning and end of each pasted line; these must be removed, or you'll get import errors. Also, make sure the LDIF file has DOS-style line endings (CR+LF), not Unix style (LF only).
• The white paper describes changing the objectClassCategory of some of the objectClasses to 3; depending on which version of the ADAM tools generated the LDIF, you may also need to set the rest of them to 1 (for some reason, it can export them with an objectClassCategory of 0, which is semi-invalid).
• The white paper doesn't detail how to index the macAddress and apple-hwuuid attributes, which is a good idea to speed computer record lookups.

Here's the LDIF file I came up with to do the extensions. These are based on a stock Windows Server 2008 R2 AD domain and OS X 10.6 server, with the 10.6 instructions from Apple and my own additions to index the macAddress and apple-hwuuid attributes. I think these same extensions will work with Windows 2003 R2 or later (note: they will not work with the Windows Server 2003 schema; you really need the 2003 R2 extensions), but they aren't very well tested with any version. Whether you use these or generate your own, test thoroughly before importing anything to your live domain controllers.

Gordon DavissonGordon Davisson

'Which of the solutions do you think is the best way to go?'

Xserve is end of life. Apple no longer offers a server class machine so Open Directory / Magic Triangle aren't really viable enterprise solutions. Judging by forum traffic, many organizations struggle with deploying and maintaining the various natives approaches, especially with updates and upgrades. OS X AppleCare support from Apple is also quite pricey.

Both Centrify and Thursby offer free trials. I'd try them both in your environment rather than take anyone's word for it.

• Centrify's business model is based on Windows AD server software, giving it the edge for UNIX/Linux integration along with the UNIX AD market leader Likewise. In Centrify's partner materials, the implication is that they don't want accounts with less than 2-300 machines.

• Thursby is a Mac specialist and requires no Windows AD server software (one of the other answer posters was mistaken in that). It also includes deployment tools and support for storage integration (DFS and CIFS) that are extras with Centrify (Absolute and ZIP respectively).

Again, best approach is to request trials and verify claims.

Shakespeare:GLENDOWER - I can call spirits from the vasty deep!

HOTSPUR - Why, so can I, or so can any man; But will they come when you do call for them?

Not the answer you're looking for? Browse other questions tagged active-directorymac-osxmac-osx-server or ask your own question.

After I wrote about building your own OpenDirectory server on Linux a while back, I decided to do the same thing on Windows Server 2008 R2. The process of extending the AD schema to include Apple classes and attributes is documented by Apple (this is the Leopard version of the document – if you don’t plan on having exclusively Snow Leopard clients, you can follow the newer version of the document that skips a couple of things that Snow Leopard no longer needs).

But since schema extensions are generally frowned upon in the Windows world because they’re irreversible (why the heck, Microsoft…?), I initially tried a dual-directory (golden triangle, magic triangle) type approach where I’d be augmenting my AD with Apple records coming from an AD LDS (Active Directory Lightweight Directory Services, previously called ADAM, Active Directory User Mode, which is basically a plain LDAP server from Microsoft). While this may sound like a great idea, I just couldn’t get it to work. After dozens of manual schema extensions to AD LDS (Microsoft doesn’t include many standard LDAP attributes, so I had to dig through the dependencies of apple.schema and even tried importing a complete OD schema), I gave up because I could not get Workgroup Manager to authenticate against it to allow me to make changes.

So the next thing to do was follow Apple’s AD schema extension guide (linked above) and do what everybody else did. This was rather straight-forward (managed preferences for users, groups and computers worked right away), but when I tried to create a computer list (which is not possible using Snow Leopard’s Server Admin Tools, but requires Tiger’s (which throw loads of errors on Snow Leopard but still get the job done) since Leopard introduced computer groups which however are not supported by the AD plugin), it just said I didn’t have permission to do that. After enabling DirectoryService debug logging (killall -USR1 DirectoryService && killall -USR2 DirectoryService), I traced it down to Active Directory: Add record CN=Untitled_1,CN=Mac OS X,DC=xxx,DC=zz with FAILED – LDAP Error 19 in /Library/Logs/DirectoryService/*. Apparently, that’s caused by some versions of ADSchemaAnalyzer setting objectClassCategory to 0 instead of 1 on all exported classes. Too bad AD schema extensions are irreversible and that’s one of the attributes you can’t change later on… 🙁 Well, with AD Schema Management MMC snap-in, I was able to rename the botched apple-computer-list class, defunct it and add a new one using ldifde. With some really wild hacking in the AD Schema using ADSI Editor, I was then able to eventually get OS X to no longer look at the renamed attribute, but instead at the new one. To see whether you have been successful, killall DirectoryService, wait a few seconds and grep -H computer-list /Library/Preferences/DirectoryService/ActiveDirectory* will show a line indicating which class in the schema it’s using.

Once you’re there, everything should work as expected. If you don’t want to use Tiger’s Workgroup Manager to create old-style computer lists, you can do that in ADSI Editor and create apple-computer-list objects in the CN=Mac OS X branch by hand.

Mac Os X Active Directory

So, attached is the schema ldif that’s exactly the way it should be. I really wonder why Apple doesn’t provide it themselves – it’s going to turn out exactly like that every time you follow their guide on any Windows server… Apple Schema for Active Directory Free email client for mac.

Active Directory For Mac

I guess that the overall conclusion of this should be that AD schema extensions in general and specifically Mac OS X managed clients in AD environments are a nasty hack. I suppose the dual directory/magic triangle/golden triangle approach with a Microsoft AD and an Apple OD would work, but it requires maintaining two separate directories, which may not be that great in a larger environment either.

Active Client For Mac Downloads

If Apple discontinues Mac OS X Server at some point in the near future (which the demise of the Xserve and the lack of announcements regarding Mac OS X 10.7 Server alongside Mac OS X Lion suggest), this is definitely something they need to improve. There are some third-party solutions that store MCX settings outside of AD (similar to Windows GPOs, which are stored on the SYSVOL share) such Thursby ADmitMac – however that’s a rather expensive solution (a dozen client licenses costs about as much as two Mac mini servers) and might break after OS updates (though from what I’ve heard, they’re rather quick at providing updates). If Apple does discontinue Mac OS X Server, they should definitely improve Lion’s AD integration to replicate ADmitMac’s features.