If you use the CD version of Mac OS X Server 10.4 to upgrade a Mac OS X Server 10.3 Open Directory Master, you will experience issues with user authentication and Kerberos. These issues do not occur if you upgrade using the Installation DVD or NetInstall.
Verifying the issue
To see if your upgraded server is affected by this issue, open the log file, /Library/Logs/slapconfig.log. If your server is affected, you will see the following messages:
2005-06-28 14:46:15 -0700 - slapconfig -migrateldapserver .... 2005-06-28 14:46:48 -0700 - 5 Updating data in LDAP ... 2005-06-28 14:46:49 -0700 - ldapdelete command output: ldap_bind: Can't contact LDAP server (-1) 2005-06-28 14:46:49 -0700 - ldapdelete command failed with status 1
In addition, you will see this overview message in Server Admin when you select the hostname of the server in Computers & Services:
"This server contains new or upgraded services that need to be configured to use sign-on Kerberos authentication. Services that already use Kerberos on this server will not be affected. Select Open directory in the Computers & Services list, then click settings."
Preventing the issue
If you can't install from DVD or NetInstall, you can still prevent the issue while using the CD if you disable Auto Server Setup prior to installation. After the installation is complete, you will be taken directly into Server Assistant. Do not complete the assistant yet. Though this would not be done under normal circumstances, you must restart the server before using the assistant. To do this, either ssh the reboot command, quit Server Assistant ( this will power off the system) or hold the power button. After restart, use Server Assistant to continue as normal.
After using the assistant, you'll need to copy a Kerberos command and preference file from another Mac OS X 10.4 system (either a server or client). To copy the "kerberosautoconfig" command from another 10.4 system, use the scp command in this manner (replacing "otherserver" with the name of the computer from which you intend to copy in the following commands):
% scp otherserver:/sbin/kerberosautoconfig /sbin
Then copy the "KerberosAutoConfig.plist" file from another 10.4 server by entering this:
% scp otherserver:/etc/mach_init.d/KerberosAutoConfig.plist /etc/mach_init.d
Alternatively, you could copy the contents of the plist file using the text below. Just copy everything below the following line, paste it into a text editor, and save it as a plain text file (not RTF) as "KerberosAutoConfig.plist" at /etc/mach_init.d/.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.
com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>ServiceName</key>
<string>com.apple.KerberosAutoConfig</string>
<key>Command</key>
<string>/sbin/kerberosautoconfig -x</string>
</dict>
</plist>
End copy above this line
Resolving the issue
If you are experiencing these issues and need to recover, follow these steps:
- On the affected Open Directory Master, open Preferences in Workgroup Manager.
- Select "Show all records Tab and Inspector."
- Click the Accounts icon, then the target tab.
- From the pop-up menu, choose Config. If you don't have replicas, skip to step 7.
- Use WGM Inspector to remove any replicas in the Config / ldapreplicas record. Leave only the master in the LDAPReadReplicas attribute. Use the Delete key—not the Delete button—then save.
- Modify the KerberosClient config record's XMLPlist attribute to list only the master, then modify the generationID as well.
- Modify the ldapreplicas config record to list only the master in the LDAPReadReplicas attribute.
- Use Workgroup Manager Inspector to add a record in /Config.
- Click New Record, and change the name to "macosxodpolicy."
- In the Open Directory settings portion of Server Admin, enable Directory Binding, then disable "Require clients to bind to directory."
- In Directory Access, configure LDAPv3, select the Open Directory server, and click Edit.
- Click the Search & Mappings tab, then reselect the Open Directory Server.
- In the Search Base Suffix window, click OK. Note your Search Base Suffix you will need to use it later, it will be something like dc=example,dc=com.
- Click the Write To Server button, then enter the LDAP root DN, such as:
uid=admin,cn=users,dc=example,dc=com and password, Search Base cn=config,dc=example,dc=com
to store the updated mappings. - If needed, set "Access this LDAPv3 server using" back to Open Directory Server, then click OK in the two panels.
- Click the Authentication tab, set to custom path, enter /Ldapv3/127.0.0.1, and click Apply.
- In Terminal, execute the following commands as root:
Note: Use your realm name for REALM. The realm name can be found in the file /Library/Preferences/edu.mit.Kerberos and is normally set to the fully qualified domain name of the server in upper case, such as SERVERNAME.EXAMPLE.COM.% kdcsetup -e % sso_util configure -r REALM -x -v 1 all % sso_util configure -r REALM -x -v 1 ldap
- You will need to get copies of the kerberosautoconfig command and plist files. Follow the steps from "Preventing the issue," above.
- Execute this command:
% /sbin/kerberosautoconfig
- Add the neighborhoods and "accesscontrols" containers. Here is an example Terminal session that adds the neighborhoods container (you will need to do the same for accesscontrols):
root# ldapadd -U locadmin -W -Y CRAM-MD5 Enter LDAP Password: SASL/CRAM-MD5 authentication started SASL username: locadmin SASL SSF: 0 <enter this text> dn: cn=neighborhoods,dc=example,dc=com cn: neighborhoods objectClass: container <press Control D> adding new entry "cn=neighborhoods,dc=example,dc=com"
If you see the message "ldap_add: Already exists (68)," the file already exists, and you didn't need to create it again, though any attempt to do so is harmless.root# ldapadd -U locadmin -W -Y CRAM-MD5 Enter LDAP Password: SASL/CRAM-MD5 authentication started SASL username: locadmin SASL SSF: 0 <enter this text> dn: cn=accesscontrols,dc=example,dc=com cn: accesscontrols objectClass: container <press Control D> adding new entry "cn=accesscontrols,dc=example,dc=com"
You may see the message "ldap_add: Already exists (68)" again; don't worry about it if you do. - To add the access controls to the directory, copy the access lines from the file /etc/openldap/slapd_macosxserver.conf to a temporary file to be edited, then remove them from the original file. Copy the following lines from ther/etc/openldap/slapd_macosxserver.conf to a temporary file so that you can safely edit them:
access to attr=userPassword by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read access to attr=apple-user-authenticationHint by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read access to attr=apple-user-picture by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read access to * by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read
The edited entries should look like this (after adding a prefix number and removing the carriage returns):
1000:access to attr=userPassword by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read
1010:access to attr=apple-user-authenticationHint by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read
1020:access to attr=apple-user-picture by self write by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read
1999:access to * by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=example,dc=com" write by * read - Use WGM Inspector to add a record in /AccessControls, click New Record, change the name to "default," then save the file.
- In the /AccessContols/default record, add each of the edited lines from step 17 as a value of AccessControlEntry. Highlight the AccessControlEntry entry, click New Value, copy and paste a line into the text field, and save. Repeat this for each line.
- Create a config record named "schema" using ldapadd:
root# ldapadd -U locadmin -W -Y CRAM-MD5 Enter LDAP Password: SASL/CRAM-MD5 authentication started SASL username: locadmin SASL SSF: 0 <enter this text> dn: cn=schema,cn=config,dc=example,dc=com cn: schema objectClass: top objectClass: container objectClass: extensibleObject <press Control D> adding new entry "cn=schema,cn=config,dc=example,dc=com"
- Modify the slapd_macosxserver.conf file to read access controls from the directory while backing up the old file, just in case:
% cp /etc/openldap/slapd_macosxserver.conf /etc/openldap/slapd_macosxserver.conf.backup
(If slapd doesn't start after reboot, you can copy back the old config file.) - Remove all "access" lines (the ones added to the directory from above), and replace with:
access specified-in-directory apple-acl "cn=default,cn=accesscontrols,dc=example,dc=com"
The Access Controls in the LDAP database should now take effect the next time you launch slapd. - Add this Kerberos record using the kadmin.local command. Use your
realm name in place of REALM, below, and your server's fully qualified domain name, such as:
# kadmin.local -r REALM -q "addprinc -randkey kadmin/hostname.example.com@REALM"
If you get a message the the policy already exists you can ignore it.
it means the principal was already there.
- Finally, execute:
% reboot