[arekdreyer]

There are a bunch of elements, and your descriptions don’t seem quite accurate.

Bottom line: if a user’s home folder is on the Xsan volume, then the user can’t log in if the Xsan volume isn’t available.

[arekdreyer]

When you set up authenticated binding, you get:
1) A computer account (or three!) created in your OD LDAP directory, so you don’t need to add it manually, if you want to add it to a computer list or computer group, and manage the computer account or computer group;
2) Kerberos principals are set up for your computer in your OD KDC (cifs, host, vnc, and clientname$), but if you’re doing the golden triangle, you won’t have OD KDC, so forget that.
3) A password server entry for your computer in your OD Password Server
4) LDAP communication encrypted between the client and OD LDAP server, but it sounds like you don’t care about that either.

So the big upside for you is that it automatically creates a computer record for your client.

The downside is that you have to provide an OD username/password every time you bind a computer to OD.

There are other means to automatically creating a computer record in your OD LDAP database…

[arekdreyer]

The login window is a terrible troubleshooting tool, unfortunately.

Are you able to confirm that you have basic authentication for the users?
You can use su, or “dscl /Search authonly username password”, – if no response from the dscl command, the authentication succeeded.

Check out the Mac OS X Directory Services v10.5 book I wrote for Peachpit and Apple Global Training; it has many pages devoted to the question.

[arekdreyer]

See pages 55-56 of “Mac OS X Directory Services v10.5” from Peachpit.

If your login window shows username and password fields, type “>console” as the username and click Login.

Then you have a black screen with a simple login prompt.

If your login window shows a list of users rather than the username/password fields, you can try pressing any arrow key, followed by Option-Return.

Or click “Other” to get to the username and password fields.

[arekdreyer]

The “no dictionary file specified” and pre-authentication notices are expected.
It looks like sbarrott authenticated successfully against the password server, and the KDC ISSUEd a ticket.

I’d suspect home folder automounts?

What happens if you log in with “>console”
http://www.macosxhints.com/article.php?story=20020318020806482

[arekdreyer]

I don’t know about Photostory, but do you have the same problem if you host the home folder via SMB rather than AFP (you’ll need to change the AD Plug-in settings with Directory Utility).

[arekdreyer]

The issue you are running into is that when you kerberized your 10.5 server’s services, you (well, the OS) created service principals based on your hostname. If you issue “sudo klist -t” you’ll see principals based on your hostname, not on the CNAME.

So you’d need to create a new service principal based on the CNAME, which you could do with kadmin.local

Then you’d need to configure each service to use the principal you just created, which I haven’t done.

[arekdreyer]

For authentication problems, I’d take a look on the server at the following logs

/Library/Logs/PasswordService/ApplePasswordServer.Server.log

/var/log/krb5kdc/kdc.log

An easy way to look at those logs is with Server Admin.
Select Open Directory in the left list of servers and services, click Logs in the toolbar, then use the pop-up menu of logs at the bottom of the window.

If you see a message like “KERBEROS-LOGIN-CHECK: no principal ([email protected])” then the kerberos principal didn’t get created.

Check your /Library/Preferences/com.apple.AppleFileServer.plist to see that the value of the kerberosPrincipal is. It should not refer to the LKDC.

For the long login problem, I’d open an SSH connection to the computer as an admin user, use “tail -f /var/log/system.log” to see if there is interesting logged. Then I’d move on to DirectoryService debugging. See http://www.mactech.com/articles/mactech/Vol.23/23.06/TroubleshootingDirectoryServices/index.html

[arekdreyer]

Now that Snow Leopard Server is released, we can discuss it in this forum.

After you install Mac OS X Server, it reboots and Server Assistant automatically opens so you can perform your initial set up. Because you haven’t yet set up your server, it uses DHCP. After you assign an IP address, you will see a window that either allows you to set a DNS name for your server, or, if there is a DNS record for your IP address, the window will display the DNS name that matches the IP address you assigned.

If the DNS service (assigned by your DHCP service) supplies a valid forward and reverse record for the IP address and DNS name you want to use, you are set.

Otherwise, your server will set up its own very limited DNS zone, with one forward and one reverse record. See page 31-34 of the Getting Started document: http://images.apple.com/server/macosx/docs/Getting_Started_v10.6.pdf

[arekdreyer]

Please do not use this forum to discuss things under NDA.

[arekdreyer]

To deselect the checkbox:

dscl -u diradmin -p /LDAPv3/127.0.0.1 -createpl /Users/theusershortnamegoeshere apple-mcxflags simultaneous_login_enabled 0

To select the checkbox:
dscl -u diradmin -p /LDAPv3/127.0.0.1 -createpl /Users/theusershortnamegoeshere apple-mcxflags simultaneous_login_enabled 1

[arekdreyer]

I’m not the most elegant script writer, but I modified a script
I already had for your purposes.

[code]
#!/bin/sh
#
# Create a folder for each user
#
# Arek Dreyer
# [email protected]
# Sun Mar 15 11:00:30 PDT 2009
#
#
# Search for users in each node.
# Note that if you search on the /Search/Users,
# you may run into duplicate users (like root 0)
# and this script’s assumptions fail.
#
# This script assumes that users under uid 1024 are system users; do not
# create any home folder for those users.
#
# Modify the variable, depending on which node you’re interested in.
#NODELIST=”/LDAPv3/127.0.0.1″
NODELIST=”/Local/Default /LDAPv3/127.0.0.1″
#NODELIST=”/LDAPv3/my.odm.com”
#
# Remove the following two lines if you don’t need
# the script to change ownership of the folders for you
# and don’t need to run the script as root.
#
echo “Note: $0 must be run as root”
[ $UID -eq 0 ] || exit 1
#
# Comment out the following two lines when you’re done testing.
/bin/mkdir /tmp/createfolder.$$
cd /tmp/createfolder.$$
#
for NODE in ${NODELIST}; do
echo “Processing node ${NODE}”
for USER in $(/usr/bin/dscl ${NODE} -list /Users) ; do
USERUID=$(/usr/bin/dscl ${NODE} -read /Users/${USER} \
UniqueID | /usr/bin/cut -d” ” -f2)
if [ ${USERUID} -gt 1024 ]; then
/bin/mkdir ${USER}
/usr/sbin/chown ${USER} ${USER}
echo “Created folder for ${USER}”
fi
done
done
[/code]

[arekdreyer]

Sorry, I should have pointed you to pwpolicy not mkpassdb.

This is probably exactly what you want:
[code]pwpolicy -a diradmin -u userxyz -setpolicy “isDisabled=1”
[/code]

You’ll be prompted for the directory administrator’s password
unless you provide the password with -p.

[arekdreyer]

You are correct – whether or not the user is disbled is not an attribute stored in LDAP.
That seems wrong at first, doesn’t it?

But remember that LDAP is only used to IDENTIFY to the user. The password server and
KDC are used to provide authentication.

So the Workgroup Manager checkbox for “User can access account” really should
be “allow user to authenticate”, but that’s too pedantic.

The “enable or not” setting is an attribute stored in the password server (isDisabled).

You can use mkpassdb to look at the user’s password server properties,
but first use mkpassdb -dump to find the user’s password server slot-ID.

[arekdreyer]

As of InstaDMG_1.4b3 (which fixes symlink issues), I include a package SetTimeZoneToChicago.pkg that creates the symbolic link as described in this thread, and it seems to work fine for me.

[Author]

Posts