ADmitMac Beta Testing (v1.0b3)

All the notes contained within this doc only apply to the v1.0b3 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.0b3 of the BETA test. Please, do NOT email concerning troubleshooting. Send all your emails to: beta@thursby.com

Old beta1 docs can be found here. Note that the extensive error message section in the beta1 docs may no longer apply to later betas.

I've written a small Cocoa app called UserInfo v1.02. It simply collects things like user name, uid, home directory, etc. and places them into a convenient menu extra on the menu bar. Add it your loginItems and it will always be ready when you login. Alternately, place it in /Users/Shared, add it to loginItems, and then copy the loginItems preferences file to the UserTemplate directory. All new accounts created will have the loginItems preferences set to automatically run the program Additionally, I've added an Applescript to this download which collects the same information and creates a tab delimited text file with it. Click here to download.

Contents

Install/Configure

• Installation
• Joining a Domain
• Using a Network Based Home Directory
• Getting Local Admin Rights
• Enable Crash Reporting

Troubleshoot/Debug

• Enable Tracing
• Using Lookupd
• Checking Your DNS
• Troubleshooting

Misc

• Common Mistakes
• Why ADmitMac is better than LDAPv3
• ADmitMac or DAVE?
• Things of Interest

1. Open the ADmitMacV1.0B3 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. Place a check by ADMitMac to enable it then click configure.
3. If you want to change your WINS servers select "WINS..." from the ADmitMac menu.
4. Click the Join Domain button.
5. By default the Computer field will be filled in with the FQDN of your computer. This is the name of the computer account that will be created in AD for your machine. DO NOT ENTER THE NAME OF A DOMAIN CONTROLLER HERE OR IT WILL BE HOSED. (If you did do this check the Microsoft Knowledge Base for the article on resetting the password on your domain controller's computer account.)
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 just enter the NetBIOS name.
7. For the Administrator Account fields enter the name and password of an account that is either a member of the Domain Admins group, the Enterprise Admins group, an account that has been delegated authority to create computer accounts, or a standard user account that has been given permission to join the particular machine you are using to a pre-created computer account already on the domain. (A bug in B3 requires that the pre-created computer account be in the Computers container. This will be fixed in B4.)
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. During this time ADmitMac has created a computer account for your machine in the Computers container in AD. 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. Select Preferences... from the ADmitMac menu. Click on the Home Directory tab. For now select local home directory and click Ok. Close the ADmitMac window.
10. Back in the Directory Access application click the Apply button if needed.
11. Click the Authentication tab. Select Custom path from the Search drop down. Click the Add button and add the Active Directory Login.
12. If you want to try the Address Book to AD integration click on the Contacts tab and repeat step #10.
13. Click Apply and close the window.
14. Logout and try logging in using a domain account

1. Run DirectoryAccess and click Configure for ADmitMac.
2. From the ADmitMac menu select preferences. Click the Home Directory tab. Select "Use Network Home Folder" or "Use Either" and click Ok. Close all the windows.
3. On the Domain, configure the user account'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.
4. 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. (You could also use the netbios form which would look like \\lilith\ritest assuming you have WINS configured in ADmitMac. However, if the domain name contains a "." or is longer than 15 characters DNS will be used to find the server.) 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.
5. 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/

NOTE: You will NOT see an icon on your desktop when the home directory is mounted in this fashion. OS X "integrates" the home directory into the file system (like NFS). To test your home directory open a Finder window and click the Home button. If Home is empty put a file into it. Select "Connect to Server" from the Go menu in Finder and connect to your home directory using AFP. Check if the file you uploaded is present. Alternately, you could always use a PC to check this.

Thrusby is looking into a way of getting local admin rights through AD but for now there is a workaround:

1. Open Terminal.
2. su to login as root.
3. Type nicl . append /groups/admin users <username> where <username> is the short name of the directory account you want to have local admin rights.
4. Test the account. A quick way to see if you have the admin rights is to open System Preferences and click Accounts. The account you logged in with should be listed as type "Admin, Network".

NOTE: To remove an AD account from the admin group su then type:
nicl . delete /groups/admin users <username>

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

To start the tcpdump trace, follow these instructions:

1. Launch the Terminal application (/Applications/Utilities/Terminal).
2. Enter this command exactly: sudo tcpdump ?p ?s 0 ?w /tmp/admitmac.trc
3. Enter your admin password when prompted.
4. Then, open the 'Connect to server' window and attempt to mount a volume (which should fail according to your message).
5. Back in the Terminal window, stop the trace by typing Control-C.
6. The trace file is stored in /tmp/admitmac.trc
   

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.

To make sure DNS is working properly, launch the terminal application (/Applications/Utilities). At the command prompt, enter:

nslookup

You should see a "> " prompt appear. At these prompts, enter these commands:

set querytype=SRV
_ldap._tcp.domain

and/or

_kerberos._udp.domain

Replace domain with your actual AD domain name. For example, use _ldap._tcp.students.school.edu if your Active Directory domain is students.school.edu You should see a list of domain controllers appear. If you don¹t, then your
domain controller is probably using a different DNS server than your Macintosh.

You can try this with the domain name "kerygma.org". You should get these results:

[paul0:~] nelson% nslookup
Default Server: xxxx.xxxx.xxxx
Address: xxx.xxx.xxx.xxx

> set querytype=SRV
> _ldap._tcp.kerygma.org
Server: xxxx.xxxx.xxxx
Address: xxxx.xxxx.xxxx

Non-authoritative answer:
_ldap._tcp.kerygma.org priority = 0, weight = 100, port= 389
host = kerygma-server.kerygma.org

Authoritative answers can be found from:
kerygma.org nameserver = BS.THURSBY.COM
kerygma.org nameserver = NS-B.THURSBY.COM
kerygma-server.kerygma.org internet address = 208.7.44.6
NS-B.THURSBY.COM internet address = 208.7.44.3

- for additional information you can enter:

_kerberos._udp.kerygma.org

You should see a list of domain controller(s) with these commands. If not, then something is wrong with your DNS setup. You might try seeing if your Mac is using the same DNS server as that of your domain controller(s). If you did get a list of DCs, next try checking your reverse lookup. ADmitMac relies on being able to reverse lookup your domain controller(s). This means that you should be able to determine the name of a domain controller from it's IP address. To check for this, use these commands, you enter the IP address of a domain controller that was returned in the list above. For example, kerygma.org has one domain controller named "kerygma-server.kerygma.org" and the above info shows that this server's IP address is 208.7.44.6 (second from the last line of output).

>set querytype=A
> 208.7.44.6
Server: xxxx.xxxx.xxxx
Address: xxxx.xxxx.xxxx

Name: kerygma-server.kerygma.org
Address: 208.7.44.6

I¹ve shown how to use nslookup to do DNS queries just like the ADmitMac does. If you get these queries to return the proper info, then joining with ADmitMac should find your domain.

NOTE: ADmitMac's reliance on reverse lookups is different that PC clients. PC clients don¹t rely on this ability. ADmitMac uses OpenLDAP and Kerberos software provided on the Mac platform by Apple and MIT. These libraries rely on reverse DNS lookups when making a kerberized LDAP connection. This reliance is not desirable, and hopefully future versions will avoid reverse lookups altogether.

"How do I get rid of a non-existent domain?"
Simply delete your /etc/krb5.keytab file from the Terminal application (assuming you don¹t use it for anything but ADmitMac). ADmitMac beta5 will allow you to delete domains without having to do this.

"How can I get local admin rights using a domain account?""When I'm installing ADmitMac I get 'DAVE cannot run with Apple's Windows Filesharing turned on. Please disable Windows Filesharing in the Sharing preferences.' "
This message, which should say ADmitMac instead of DAVE indicates that Samba (a.k.a. Windows File Sharing ) program was running at the time of install. To verify, open a Terminal (Applications/Utilities/Terminal ) and type the following commands:

ps ax | grep nmbd <enter>
ps ax | grep smbd <enter>

Note: The '|' characters are pipe symbols, not the letter 'i' or 'L'.

If either of those two commands show any output that looks "similar" to the following line, then Samba is on.

451 ?? S 0:00.68 nmbd

If you don't see any output after using those commands, check if there is a file in the /tmp folder called com.thursby.samba_active. Delete it and try installing again. If you do see this output try checking disabling Windows File Sharing in System Preferences/Sharing.

"How can I make OS X ignore WINS information from DHCP?"
This is not the greatest solution for you by any means, but it is a workaround.

1. Open a Terminal window and type:
   sudo killall cifsd <enter>
2. Open the /Library/Preferences/com.thursby.DAVE.cifsd.plist in a text
   editor.
3. Search for the string 'Use DHCP'. Set the associated value (which
   should be <true/>) to <false/>.
4. Restart the cifsd by typing: /System/Library/Filesystems/DAVE/cifsd.app/Contents/MacOS/cifsd
5. Use the ADmitMac Configuration tool to set or unset the WINS servers.

"My Mac is locking up on 'waiting for network file services'"
This tends to be caused by a DirectoryAccess configuration (ADmitMac, LDAP, whatever) causing the Mac to get stuck. This can be either caused by misconfiguration or possibly some network/DNS issue. You can "reset" your DirectoryAccess setting by:

• Login with local account. If the computer won't do this boot to single user mode (Command-S during boot).
• cd to /Library/Preferences/DirectoryAccess
• Delete all files. They will be recreated when you run the DirectoryAcess program again.
• Reboot.

"How do I uninstall ADmitMac?"
Run the install program. From the popup menu select Uninstall.

"How do I manually uninstall ADmitMac?"
Please avoid doing this. ADmitMac comes with its own uninstall program (see above). If your Mac is locking on 'waiting for network file services' consider "resetting" your DirectoryAccess (see further above).

To manually remove ADmitMac you only have to remove the following items:

/Library/DirectoryServices/PlugIns/CIFSPlugIn.dsplug
/Library/StartupItems/CIFS

However, if you really want to pristinely remove all files, you will need to delete all of the following:

/sbin/mount_cifs
/System/Library/Filesystems/DAVE
/System/Library/Extensions/NetBIOS.kext
/System/Library/Extensions/cifs.kext
/Library/Application Support/ADmitMac
/Library/DirectoryServices/PlugIns/CIFSPlugIn.dsplug
/Library/Documentation/Help/ADmitMac.help
/Library/Frameworks/Thursby.framework
/Library/PreferencePanes/MyNetworkAccount.prefpane
/Library/Printers/DAVE
/Library/StartupItems/CIFS
/Application/Utilities/ADmitMac Network Utility
/System/Library/Extensions.kextcache
/Library/Preferences/com.thursby.*
/usr/libexec/cups/backend/cifs
/tmp/com.thursby.DAVE.cifsd.API
/tmp/com.thursby.DAVE.cifsd_dns_helper

Depending on how you have used the product, you may also need to remove the following files:

~/Library/Application Support/ADmitMac/ADmitMacConfigTool
~/Library/Application Support/ADmitMac/PluginConfigHelperTool
~/Library/Preferences/com.thursby.ADmitMacConfiguration.plist
~/Library/Preferences/com.thursby.ADmitMacNetworkUtility.plist

Keep in mind that if you do not run the actual uninstaller, you will need to go into Directory Access at some point and
remove the authentication paths from the Authentication and Contacts tabs. Also, if you wish to use Apple's built-in SMB service after you remove these files, you will need to manually check that box in Directory Access (these steps are done by the uninstaller, typically).

"I have a Windows Server 2003 (formerly Windows .NET Server) and I can't mount CIFS shares."
Verify 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. See issue above.

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

"I'm unable to join the domain."
This problem can 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. If you

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.

Its possible if WINS is being used that the WINS server detected on install doesn't contain the record for finding the DC for your domain. You can manually change the WINS server by loading DirectoryAccess, configure ADmitMac, and then select Preferences from the ADmitMac menu. NOTE: If DHCP is pushing WINS configuration down the WINS entries you put in maybe overwritten Check for another troubleshooting tip on how to work around DHCP pushed WINS configuration.

"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 specified that ADmitMac use a local home directory or if a network home directory is specified make sure the path has been configured into the user account.
• Use the shortname (login name) for your user name when logging in.
• Check that your username and password are correct by logging into a PC on the same domain.

"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 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 pre-authentication. 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.

• 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.
• Make sure your Domain Controller has a reverse DNS lookup entry and that its correct.
• 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.

• You should not have to change settings in your domain (namely home directory information). ADmitMac uses the same home directory info as PCs use.
• Secure LDAP access without the need for ssl, and no LDAP password saved on the Mac.
• SMB mounts that work using DFS.
• SMB mounts that work when the home directory is in a path where the user can't look it folders between the share and the home folder.
• SMB mounts that are fully compatible with Services for Macintosh.
• Works with NT domains.
• Published volume browsing.
• Published printer browsing (will be in B4)
• Credential caching (will be in B4)
• Password change at login, expiration warning, and ability to change password.
• No schema changes and no repurposing of schema attributes

Since both ADmitMac and DAVE accomplish similar tasks you might wonder why one or the other. Thursby's response was the following:

ADmitMac is targeted towards labs/corporate desk/laptops where:

1. The administrators want centralized control over who can use the Macs using their existing (i.e. no schema changes, etc.) Windows administration scheme.
2. Want to use network home directories for 'roaming user' purposes.
3. Be able to browse and mount/print SMB resources advertised via NetBIOS (DAVE client functionality) or published via AD.

DAVE is targeted (and priced) toward the end user who has their 'own' Mac. You get the ability to browse and mount/print SMB resources. You also get preference panes to change your workgroup, NetBIOS name, interfaces, etc. which may be useful if you are constantly roaming between radically different Windows networks, and the ability to configure your machine as an SMB file/print server.

If you have ADmitMac, and don't need the DAVE server functionality then you shouldn't be missing anything.

• If you login with your domain account and lock your computer with the screensaver, you might not be able to log back in again. Sometimes the login is accepted but a delay of 2-3 seconds occurs. Thursby is aware of this. You can use the local admin account to bypass this problem.
• Applescripting options for ADmitMac are being considered by Thrusby.
• Login script processing is being considered by Thrusby.
• Cached Credentials (so you can login using your network based account even when you're not connected to the network) have been implemented in beta 4.
• Having local admin rights while logged in with an AD account is being considered by Thursby. (beta 5)
• Support for a user template (like the one Apple uses when creating local accounts) is being considered by Thursby. (beta 5)
• 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.
• 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.
• Removing the domain you've joined is complicated if the domain is not reachable. (ie - you have to manually delete files) (fixed in beta 5)
• ADmitMac DOES handle DFS (Distributed File Services) but you should note that:
  
  ADmitMac handles DFS a little different then Microsoft. This has to do with some limitation of the current OS that we hope to have corrected in the future. So let me explain the two different process.

  If the mount URL (Connect To Window, Terminal Window, or Home Directory path) contains a DFS Link we will translate it before we do the mount.
  
  If you mount a DFS Root then once you double click on a DFS Link we will mount it on the desktop. The folder you opened will be empty, but the Link will be mounted on the Desktop. We (Thursby) would like to change this in the future so you will be able to just drill down the DFS links path.

• ADmitMac support share names longer than 12 characters however you must PUBLISH the share in active directory. On a Windows 2000 server you:
  • Open Active Directory Users and Computers
  • Right click on the OU of your choice and select New/Share.
  • Enter the info for the share name and the name to publish under.
    
    If you are running Windows Server 2003 (aka - .NET server)
  • Go to File Server Management, select Shares (Local) then do a Property on the share.
  • Select the Publish Share Tab and mark it to be Publish.

04/28/03 - Updates
04/18/03 - Updates
04/16/03 - Updates
04/15/03 - Updates
04/11/03 - Upated
04/10/03 - Created Document