ADmitMac Beta Testing (v1.0b1)

All the notes contained within this doc only apply to the v1.0b1 of the ADmitMac beta test. Future BETAs of this software may operate differently requiring different install and troubleshooting procedures. The concerns I've listed at the end of this document only apply to v1.0b of the BETA test. Please, do NOT email concerning troubleshooting. Send all your emails to: beta@thursby.com

1. Open the ADmitMacV1.0B1 image and run the install program.Keep clicking continue until its completed.
2. After the ADmitMac configure program launches find the installer prompt (its still there) and click Quit to shut it down.
3. In the ADmitMac configure program, click the lock icon, authenticate, then click Continue.
4. During the config any WINS server you have on the network should be detected and configured into ADmitMac as primary and secondary WINS servers. You can change these later. Click continue then click Quit.

1. Open the Directory Access application. It can be found in the Utilities folder in the Applications folder. Authenticate if needed by clicking the lock icon.
2. Make sure that BSD Configuration Files is NOT enabled.
3. Place a check by ADMitMac to enable it then click configure.
4. If you want to change your WINS servers select "WINS..." from the ADmitMac menu.
5. Click the Join Domain button.
6. If you are joining to an AD domain make sure that Active Directory Domain is checked (though it can work without it). In the Domain field enter the FQDN of your domain. NT4 users should probably just enter the NetBIOS name (not sure on this). So, on my test rig I have the server LILITH which is the DC for ABSYNTHESPAD.COM. In the domain field I enter ABSYNTHESPAD.COM.
7. For the Administrator Account fields enter the name and password of an account that is either a member of the Domain Admins group or the Enterprise Admins group. An account that has been delegated rights to create computer accounts will NOT work.
8. If everything works there will be delay followed by the closing of the window and the addition of your Domain to the ADmitMac config list. Close this window. During this time ADmitMac has created a computer account for your machine in the Computers container in AD. If you look at it you'll notice the Mac's serial number has been added to the account as a comment. Neat. Additionally, on the local system the edu.mit.Kerberos file will have been generated in /Library/Preferences if one didn't already exist. Otherwise, entries are adding to the existing file. Remember this as you may need to look at it later. Additionally, a krb5.keytab file is generated in /etc.
9. Back in the Directory Access application click the Apply button if needed.
10. Click the Authentication tab. Select Custom path from the Search drop down. Click the Add button and add the Active Directory Login.
11. If you want to try the Address Book to AD integration click on the Contacts tab and repeat step #10.
12. Click Apple and close the window.
13. If you turned off BSD Configuration you may need to reboot.

1. If you haven't already create an account in AD to test with. Make sure the Home Directory field is blank.
2. Open the terminal and do SU to root (you can also SUDO this but I prefer SUing).
3. CD to /Users. MKDIR the user directory and name it after the user's short name (login name). For my test account of ritest I entered: mkdir ritest
4. CHOWN the user directory to change ownership to the user. For my test rig I entered: chown ritest ritest
5. Optionally, CHGRP to set staff as the group on the user directory. In my test rig: chgrp staff ritest
6. If you wany privacy, you can also CHMOD 700 the directory to block everyone out. Again, on my test rig its: chmod 700 ritest
7. With everything set you can logout and now login using the domain account. Only the account you've created user directories for will work.
8. If Finder reports the home directory is missing try rebooting. If its still a problem, try creating Domain directory on the root of the drive. Create a Users directory beneath it. Then make another home directory for the user in there following steps #3 through #6.

Thursby asks that we enable crash reporting just in case a crash actually occurs. This way if a crash does occur some log of it will remain.

1. To do this, open the Console (located in Applications/Utilities).
2. Select 'Preferences' from the console menu and click on the 'Crashes' tab.
3. Check the first box to enable crash reporting. If you would like to know when a crash occurs, you can also check the second box to "Automatically display crash logs". If a crash occurs, the log will be saved in /Library/Logs/CrashReporter.

For additional troubleshooting information you can enable an option called tracing.

1. Open the ADmitMac configuration program.
2. In the ADmitMac menu of the ADmitMac Configuration utility that enables tracing. Turn this on, and then log out. Do not reboot or it will not trace any longer.
3. Try to log in with your domain account a couple of times. Then, log in with your local account and check the log file. Its located in: /var/log/system.log

A handy troubleshooting tool is lookupd. Lookupd allows you to query the NetInfo/LDAP/Directory Access hiearchy so that you can see if the domain data is being found and what that data looks like.All commands in lookupd are case sensitive so make sure to capitalize as needed. To use it just:

1. Open a terminal window.
2. Type lookupd -d <return>
3. Type ? <return> for a list of commands.
4. One useful command to try is: userWithName: <domainuseraccount> This will tell you if the <domainuseraccount> is being seen. If its not you have either mispelled the user account short name or your machine isn't connecting to the domain.

"I have a Windows Server 2003 (formerly Windows .NET Server) and I count mount CIFS shares."
V erify that digital signing is not set to be required by the server. There is one security policy that says it is required (server-side) and one that says to use it if it can be used (server-side). If the one specifying that it is required is enabled, then you will not be able to connect to it.

"I'm having problems accessing resources using DAVE or ADmitMac but my PCs are fine."
If you have digital signing enabled in AD neither ADmitMac or DAVE will work properly.

"How do I completely remove my kerberos settings?"
You need to delete two files as the root user (either sudo or su).
/Library/Preferences/edu.mit.Kerberos
/etc/krb5.keytab
The next time you join an AD domain using ADmitMac these files will be regenerated. If you join an NT domain kerberos is not used. If you already have Kerberos settings backup the file and add them back in later.

"Unable to join Domain"..."Network is Down"
You are using an account that is not a Domain Admin to join the computer to the domain. Using an account that has been delegated rights to create computer accounts will NOT work.

"Route to domain not found"
Check your edu.mit.Kerberos file (in /Library/Preferences) for the default realm name. Whatever is listed as the default realm name is what you should use in the domain name field. Also, make sure that whatever is configured for the default realm actually points to the correct server. If you have multiple realms configured find the entry for the realm (domain) you're having problems with and make sure you're spelling it correctly and that its pointing to the right server (i.e. - a domain controller for that domain)

This error can also occur if you don't have reverse DNS lookup or if its configured incorrectly. Make sure that you have a proper reverse DNS record for the DC you are trying to join the domain from.

Your DNS server must return a service record for your domain controller. If you are using a Microsoft DNS server (like the one that ships with Windows 2000 server) this is handled automatically. If you are using something else make sure it supports service records and is configured correctly. I don't have any specifics on this but I suspect the Microsoft web site and many other places have the information.

"I've joined the domain successfully but I can't login to it."

• Check that you've added a custom authentication path in Directory Access. Without it OS X won't use your AD connection for account authentication. If you get the window shake immediately without pause check this first.
• Make sure you've created the user's home directory. Without it you can't login at all.
• Make sure you have unchecked BSD Configuration Files in Directory Access. If you do turn this you may need to reboot before it takes affect.
• Use the shortname (login name) for your user name when logging in.
• If you are getting a "KRB5 error code 52" in your trace log it might mean the account you are using is in too many groups. http://mailman.mit.edu/pipermail/kerberos/2002-May/001014.html (This is uncomfirmed right now.)

"When I try to join the domain I get Unable to join domain: No such Process."
This can happen when you have a pre-existing computer account left over from a previous domain join or one that has the same name as the computer you're attempting to join. Either change the name of the computer or find the computer account in the Computers container on the domain and delete it.

"Finder reports that its unable to find the home directory."
For some reason Finder is looking for the home directory in /Domain/Users yet there is also an expectation that the home directory has to be located /Users. I don't know why this happens but it appears it can be fixed by either rebooting or creating a user directory in /Domain/Users as well as /Users. You'll need to create the Domain and Users directories and make sure Everyone has at least Read privledges on both otherwise the login account won't have the rights needed to browse to the home directory. This shouldn't happen and oddly on my box it disappeared after a while and started using the home directory in /Users.

"I get the KDC has no support for encryption type error."
This seems to occur when you reference an AD account that Kerberos just can't communicate with. Resetting the password for the account using a PC can fix this. I've also discovered the Administrator account on my test rig causes this error. The work around I came up with was to create a separate test account and add it to the Domain Admins group.

"I can't get the Mac to mount its home directory from the server."
When you configure the user's profile tab select Connect in the Home Folder section. Ignore the drive letter unless you plan on using a PC with this account as well. Enter a path to the home directory CIFS share, the form I used was: \\lilith.absynthespad.com\ritest This is the path to the home directory SHARE. The actual location of the home directory was C:\Users\ritest. When you do login with a home directory set in this manor a local home directory is auto created and the Finder is directed to it. ADmitMac will create a folder at the root named Domain in which is a Users folder. In that you'll find an alias to the server based home directory. Why this is done or what interaction takes place between the two I don't know. If you still can't get the home directory to work login with a local account and then check if you can CIFS mount the home directory share from there. Press CMD-K and in the connection dialog enter: cifs://server/share/

"I'm get the error Device power is off when I try to join the domain."
This occurs if you are attempting to join to the Active Directory domain controller, but there is a problem with
the DNS records on your DNS server for the domain controller (i.e. the name of the PC does not match the DNS record). This can also happen if you are using WINS and the WINS server is in a different subnet from the DC you are trying to join against.

"I received an error that looks something like Error #4426862688"
This seems to be displayed when there is no DNS server specified in Apple's Network system preference. This could possibly be displayed if an invalid address was used for the DNS server in that system preference or if the specified DNS server is invalid and there are no backup DNS servers listed.

"I'm receiving the error clock skew too great. What is this?"
This means there is a time difference between the domain controller and the client Mac that is too great to allow Kerberos preauthentication. If the two times are more than 5 minutes (or so) off, this error will be given. Change the time
on one of the machines so they are more closely matched.In a production network you might consider network based time sources (NNTP). In an AD network, I believe any DC can be used as a time source though you should be certain the DC you use has the resources available to handle Mac time syncs.

"Domain logins with ADmitMac are slow."
(taken from Paul Nelson's email) The version of Kerberos used by ADmitMac is 1.2.7. This version supports using DNS to locate realm and KDC information. On some networks, this may cause delays logging in. If you experience one or two minute delays logging in, but the login works, you might try adding the following lines to your /Library/Preferences/edu.mit.Kerberos file. Put the lines in the [libdefaults] section:

dns_lookup_kdc = false
dns_fallback = false
dns_lookup_realm = false

• The password AND username are case sensitive. You have to get both of them right.
• The Active Directory domain name must be a fully qualified name.
• Trying to join an NT domain with the Active Directory option checked will NOT work.
• Make sure the Mac is using the same DNS server as the Active Directory domain controller.
• If you are receiving "KDC has no support for encryption type" during login try changing the password to the account from a PC then try again. This problem is caused domain accounts created prior to the creation of an AD domain, accounts that have been migrated from an NT domain to AD, or when an AD account is newly created but has not had its password set by the Administrator.

In BETA testing I've noticed the following things:

• Computer account is created but it has DELEGATION turned on. This is a bad thing.
• When adding a domain the edu.mit.Kerberos file is automatically created, however the default_realm will only be set to the first domain you've configured.
• If the domain account you use to join doesn't have rights to remove computer account ADmitMac works fine but the computer account is left behind. No alerts are generated in the GUI.
• To join a computer to the domain the account you use must be a member of domain admins. Delegation doesn't work.
• If a computer is removed and then added to the domain again, the UIDs it sees for AD accounts will change. The UIDs appear to be client specific.
• If you have a screensaver enabled to use your login account for authentication. It won't let you back in to the machine unless you use your FULL NAME.

04/08/03 - Minor Update
03/20/03 - Minor Updates
03/19/03 - Minor Updates
03/14/03 - More updates
03/13/03 - Updated with Common Mistakes section (largely taken from ADmitMac help file)
03/12/03 - Created Document