[AMSR]

With a system “connected to a directory system”, meaning its not a replica or a master, but you want people to be able to log into it via their OD name and kerberos password (single sign on), you need to bind it to your OD system using Directory Access. Then, if you haven’t already, add the new system to a computer list in WGM on your OD system and make sure you use the fully qualified domain name of the server. (ie server.example.com, as opposed to just ‘server’). And then finally in Server Admin click the “join kerberos” button. The first step establishes communication with the LDAP server, and the third step creates entries in the OD master called “service principals” for your new server. This third part is what tells your OD master to hand out kerberos authentication tickets for services on your new server, even though its not an OD server itself. Its considered part of the “realm”. If you really want to check it out on a more detailed level you can log into the OD master and use the kadmin.local command to run the “listprincs” command. This will allow you to list from the KDC all of the known hosts and services they offer via kerberos. Kerberos service principals are in the format of “service/[email protected]”. By default, when you click the “join kerberos” button in server admin, OSX server creates on the ODM’s KDC 3 of these entries for each service on the it provides for the host you are “joining kerberos” from…

[AMSR]

When you bind your Mac to AD, it requires the time to be in sync with the AD server, not only that its the right time. So you might try putting in the address of the domain controller (usually the one hosting the GC) and their DNS root as the NTP server. Typically people run NTP on their DNS servers, but only they can give you this info. I mention this because if time.apple.com is not what they are syncing their AD domain to, you may still have problems.

The AD plugin uses Kerberos to bind, even if your file sharing users aren’t intended to user Kerberos to connect. When you initiate a bind, AD creates a shared secret between the domain and your server called a “principal” and this is a Kerberos thing. This shared secret between your server and the domain is secured with a “machine password” just as users accounts are secured with a “user password”. If this shared secret gets broken (such as the machine password is changed), your server will be unable to talk to AD anymore. AD requires all computers that talk to it to have valid machine account (thus valid machine passwords).

On a more practical note, I’d try to see if they can put your server’s computer object in an OU that doesn’t have a policy applied to it to change the machine password on a periodic basis. Your other alternative is to have your client use the ADmitmac AD plugin, which will get you this functionality.

[AMSR]

You also mention you are using Jag server (10.2.8) as your OD master. While in theory this might work, I’m not sure you you are getting this to talk to AD (via LDAP maybe?) Also, I’m not sure the “magic triangle” was ever intended to be implemented with Jag. I’d try making my OD servers at least 10.3.9.

[AMSR]

What you probably need to do is get the users in a group in OD. Then, using the “login itmes” preference in OD, mount and drag whatever volumes you want mounted on login to the login items panel in WGM and check the “mount with users name and password” box. Then, after your end users log in with their AD password, it will try to use the same name/password to mount whatever share is in that panel, if the user evaluates to be part of that group.

As far as the home folder, there are a host of issues surrounding that. How is it specified in the UNC path field in AD? What are the permissions set as on the Windows server? (You need list access for all parent folders) Do you have SMB signing enabled on the win2k3 server?

[AMSR]

If you switch the AD plugin on the Macs to use AFP, does it work? I’d be curious…

[AMSR]

Once you have bound to AD, and are logged into the computer via the local admin account, can you resolve the users ID via the “id” command at the terminal?

Can you manually chown a folder to that user’s AD name?

I’ve not seen this one before, I’d be curious if this is a bug. You might try reporting it as such at http://bugreport.apple.com (you need a free ADC account) and see what they say.

[AMSR]

Follow this article:

http://docs.info.apple.com/article.html?artnum=300765

Basically, both AD and OD push a kerberos config file to the clients. If you are bound to one or the other individually, this is what you want. If you are bound to both, you only want one. The client tries to be smart and merge the two, but sometimes the AD doesn’t respond fast enough and you only get the OD info. Then, when you try to go log in with an AD user it doesn’t work. This goes for both 10.3 and 10.4 OD masters in the “magic triangle” setup. Once you follow that article and change the KerberosClient record on your OD, you should reboot your clients so they re-generate their info. You may also want to re-establish any replicas you had made.

[AMSR]

What does the system.log say on your OSX client after you log in. Is it trying to mount your home? Also, what does the UNC path for the home folder look like in AD? It should be \\servername\sharename\homefolder. All folders that are parents of the home folder need at least list access for the person trying to access the home.

[AMSR]

Try deleting the /Library/Preferences/DirectoryService/DSLDAPv3.plist file. You can also go into netinfo manager and delete any MCX_caches as well as deleting any MCX plists in /Library/Preferences. Removing the DSLDAPv3.plist will clear out the LDAP stuff.

[AMSR]

Instead of manually editing the edu.mit.Kerberos file and using /etc/authorization to enable TGT on login, you should probably be binding your clients to AD using the AD plugin. You can then bind them to OD as well to get your MCX settings. Just make sure the OD server is listed after the AD server in the authentication path. You should also disable the kerberos auto config by OD by following the instructions in this article:

http://docs.info.apple.com/article.html?artnum=300765

If you don’t you will get conflicting OD and AD KDC info in your edu.mit.kerberos file.

FWIW, I have not seen anyone able to get the /etc/authorization trick to work on 10.4.

[AMSR]

On your emulex, you should set all ports attached to storage as “Target with Stealth” and all ports attached to HBAs as “Initiator with Stealth”. If your emulex is actually a switch, you should be OK. Most emulex boxes aren’t actually true fabric, but act more like hubs (the 355 and 375). On those switches, you should set the HBAs on your clients manually to 2GB/Arbitrated loop. I don’t know much about the emulex siwtches that are actually fabirc, so i don’t know if you need to manually set speed/topology on those.

[AMSR]

I agree the Apple card is an LSI card and will work with the LSI windows drivers. However, Apple only supports it on OSX. I’d probably buy the actual LSI card from LSI so you can get support. The Qlogic cards work great too.

[AMSR]

If you don’t use mobile accounts you can still do this. Instead of creating an automount record in OD to assign to your users in the “Home” tab of WGM, just assign them to “/Users/shortname”. The first time you do this, it will add “/Users” as an option for homes, and any use you assign in this way will create a local home (using their OD shortname as the folder name) in /Users on each local machine.

There is a good summary of how to do this in the XSan admin guide on Apple’s site. Because of performance implications for FCP, this is the recommended way to do things with XSAN in a video environment. Suffice it to say, even if you aren’t doing that, the instuctions in the XSAN guide will help out out.

[AMSR]

You might want to check out Elektron Enterprise Edition from corriente systems. I have heard good things. It backends radius into OD.

[AMSR]

The AD plugin should try to mount the home specified in the “Profile” tab in the Account Properties pane in AD. Note, that you will need at least “list” permissions on all of the folders up to and including your home directory for it to mount. The AD plugin takes the UNC path to the home and converts it to URL type string like:

\\server\folder\home

smb://server.example.com/folder/home

It then tries to mount the share on the desktop using AFP or SMB, whatever you select.

As for the group policies, the Mac has no idea what windows group policy objects are all about. What you’d need to do is either extend the AD schema with the Apple management schema (this would allow you to use workgroup manager against AD and manage your macs), or use an Open Directory server in addition to AD to supplement the management data.

[Author]

Posts