Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Cannot log into OpenDirectory server

I am running OSX Server 2.2 on a Mac Mini with 10.8.5. I have successfully enabled Open Directory and created several users that are set up as Services Only, as they do not need home directories, only file sharing and (hopefully in the future) contacts and single sign-on.


I am able to bind my computer to the OD server using the fully qualified domain name (internal.xxxx.org) and get the green "enabled" dot in the Users page on the Mac.


I turned on "Allow Network Users to Log In" and tried to log in as my network user, and it "shakes" when I enter the username and password, and won't log in. What am I doing wrong? I'm unclear how to log in as a network user from my Mac's sign-in screen. I also tried using the administrator's account, which is an actual user account on the server and that did not log in either. It doesn't seem like the Mac is even attempting to check the server for user information.


Thank you.

Mac mini, OS X Mountain Lion (10.8.5)

Posted on Oct 13, 2014 2:28 PM

Reply
19 replies

Oct 14, 2014 4:13 PM in response to Linc Davis

I wasn't specific enough. I can log in via remote desktop, screen sharing, etc. using the local user, I just can't log on through Open Directory. For example, I log off of my desktop and click the icon on the sign-in screen for Other User, and then type in my network username and password, and the password box shakes. I tried this with several users that are set up as Services Only users, but also the main administrator which is a local account on the server. None work - it also doesn't seem like it's even trying to reach the server because there's no delay whatsoever from when I type the password and hit enter to when it denies access. I successfully bound to the OD server using the administrator log-in when adding it, and I have the green "light" in the User system preference.

Oct 14, 2014 4:45 PM in response to JSP196

Have you enabled mobility for the account(s)?


You need to enable Mobility on the user accounts. As is, the accounts on the server are just accounts with SACLs applied. You have not defined a policy to tell those accounts to function as mobile accounts.


You have two options to enable this. The first is the old way... MCX. While this will still work in Mavericks, MCX as a technology is deprecated so don't expect it all to work (it doesn't). To set MCX you need to download Workgroup Manager and then enable the Mobility settings on individual users, a group, or on a computer group.


The second option is to use Profile Manager. If you decide to go this route, you must have proper DNS, an Open Directory Master running, a third party signed SSL certificate helps but is not required, and you setup your accounts as Local Network Users. These accounts must have a valid NFSHomeFolder value. Then in addition to binding the workstations to the domain, you also must enroll them in to Profile Manager. At this point you can define policies and once again the one you want is the Mobility profile.


The accounts are not very smart. You must apply policy to those accounts to tell them how to behave in relation to the workstation.


Reid

Apple Consultants Network

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Oct 14, 2014 5:10 PM in response to JSP196

Many Open Directory problems can be resolved by taking the following steps. Test after each one, and back up all data before making any changes.

1. The OD master must have a static IP address on the local network, not a dynamic address.

2. You must have a working DNS service, and the server's hostname must match its fully-qualified domain name. To confirm, select the server by name in the sidebar of the Server application window, then select the Overview tab. Click the Edit button on the Host Name line. On the Accessing your Server sheet, Domain Name should be selected. Change the Host Name, if necessary. The server must have at least a three-level name (e.g. "server.yourdomain.com"), and the name must not be in the ".local" top-level domain, which is reserved for Bonjour.

3. The primary DNS server used by the server must be 127.0.0.1 (that is, itself) unless you're using another server for internal DNS. The only DNS server set on the clients should be the internal one, which they should get from DHCP if applicable.

4. Follow these instructions to rebuild the Kerberos configuration on the master.

5. If you use authenticated binding, check the validity of the master's certificate. The common name must match the hostname and domain name. Deselecting and then reselecting the certificate in Server.app has been reported to have an effect in some cases. Otherwise delete all certificates and create new ones.

6. Unbind and then rebind the clients in the Users & Groups preference pane. Use the fully-qualified domain name of the master.

7. Reboot the master and the clients.

8. Don't log in to the server with a network user's account.

9. Disable any internal firewalls in use, including third-party "security" software.

10. If you've created any replica servers, delete them.

11. As a last resort, export all OD users. In the Open Directory pane of Server, delete the OD server. Then recreate it and import the users. Ensure that the UID's are in the 1001+ range.

Oct 20, 2014 6:26 PM in response to Linc Davis

So to update - I have configured DNS properly. I followed the Kerberos instructions. The certificate is valid (though it's locally generated, not third-party.) I unbound and rebound the server to the client computer. I rebooted the master and the client. I'm not using any firewalls or replica servers.


I also went into Profile Manager and added my person Mac to my list of devices and then enabled Mobility. I now have two items listed in Profile Manager on my local computer - one for remote management and one for mobility. I set these up using profile manager, not MCX (because I don't know how to do that).


I've unbound and rebound the server to the client, I've restarted both the server and the client (and have not logged into the server directly) and we're not running any firewalls on our internal network. There are no replica servers. All users are in the 1001+ range when I looked to see people's user numbers.


The users are all still Network Services users only since I don't want anyone having network account storage or remote home folders. Really the sole reason I'm hoping to use OD is so that when people sign into their computer they automatically authenticate to the server to allow for easier file sharing and so that I can then use Google's API to tie that authentication into their email accounts.


Thanks.

Oct 21, 2014 3:54 PM in response to JSP196

From the bound machine what results do you get when you run the following commands:


id username


Replace username with the short name of a user created on the server.


kinit username


Replace username with the short name of a user created on the server. In this case, you will be prompted for the user's password. Enter it. When you hit return, what is the result.


If the result is another command prompt, then run


klist


Did you get a TGT from the server?


Reid

Apple Consultants Network

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Oct 21, 2014 4:57 PM in response to Strontium90

id username (using my local username)

uid=501(Jeffrey) gid=20(staff) groups=20(staff),206(com.apple.access_loginwindow),12(everyone),33(_appstore),6 1(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),100( _lpoperator),204(_developer),1029(workgroup),402(com.apple.sharepoint.group.1),4 01(com.apple.access_screensharing)


id username (with my network short name)

uid=1041(jport) gid=20(staff) groups=20(staff),1030(GAA),206(com.apple.access_loginwindow),1026(administratio n),1033(GCT),12(everyone),62(netaccounts),80(admin),402(com.apple.sharepoint.gro up.1)

kinit

Did give me another command prompt

klist

Credentials cache: API:501:3

Principal: jport@INT.XXXXX.ORG

Issued Expires Principal

Oct 21 16:54:41 2014 Oct 22 02:54:40 2014 krbtgt/INT.XXXXX.ORG@INT.XXXXX.ORG

Thanks!


Jeffrey

Oct 21, 2014 9:31 PM in response to JSP196

Ok, so this is looking very good. The first command (id) returns a truncated record response. The uid=1041 suggests this is a domain user who belongs to the groups: 20(staff),1030(GAA),206(com.apple.access_loginwindow),1026(administration),1033 (GCT),12(everyone),62(netaccounts),80(admin),402(com.apple.sharepoint.group.1)

So you are getting results back from Open Directory. This would suggest that you are properly bound and the machine is trusted.

The second command, kinit username, is the Kerberos Initialization command. It prompts for password but in the background does a Kerberos credential exchange. This is what requests the TGT. If it accepts the password than the assumption is that DNS, Time, and all other trust requirements are in place. The user's password was accepted and you received the TGT.

The third shows us the TGT. The krbtgt is the Kerberos Ticket Granting Ticket. This is the keys to the kingdom.

So basically, it looks like your infrastructure is configured properly.

So this leads me to question two more things. What is the shell and NFSHomeDirectory values of the user account? To find out, run this command on the server:

dscl /LDAPv3/127.0.0.1 read /Users/jport

The items of interest are:

UserShell

NFSHomeDirectory

The UserShell should be something like /bin/bash. The NFSHomeDirectory should be /Users/jport.

Reid

Apple Consultants Network

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Nov 10, 2014 5:11 AM in response to JSP196

You need to set the attributes to valid values.


UserShell /usr/bin/false means the user has no shell. Set this to /bin/bash.

NFSHomeDirectory /dev/null means the user has no defined home folder path. Set this to /Users/shortname where shortname is the user's short name. This is by convention by the way. You can make the path anything you want as long as it is in the /Users/ directory (again, convention, but logical convention).


Reid

Apple Consultants Network

Author "Yosemite Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Nov 11, 2014 11:47 AM in response to Strontium90

Thanks. If I do that, is there a way for me to also set it so that the user does not use that home directory? Based on the way our staff uses the network, most data gets stored locally.


And in terms of convention, if I have a folder structure that's /<company name>/<users> on an attached RAID array, can I use that as their storage as well? Any disadvantage to that?


Thank you!

Nov 11, 2014 12:32 PM in response to JSP196

I think you are mixing up the types of accounts you can have. Here is a basic rundown:


• None - Services Only: This type contains no home folder value in the NFSHomeDirectory key. This type of account also does not create a home folder on the server. Personally I like to start this way to avoid creation of a home folder on the server's boot volume. These accounts are fine for non-centralized environments in which the workstations are not integrated into the domain and everyone is a local admin.

• Mobile Accounts: This is an account that can log in from a domain bound machine. This account exists on the domain but the user can log into the machine with domain credentials. If the NFSHomeDirectory value is set to /Users/name that the home folder is created on the machine that you log in from. The account is not cached and access can only be gained if the machine can reach the domain. The machine must be bound to the domain.

• Mobile Cached Accounts: This is an account type that requires both binding and enrollment into Profile Manager (or the use of MCX). This account exists on the domain but the user can log into the machine with domain credentials. By adding management, the account attributes are cached to the machine for offline use. The home folder is created on the local machine and the user record exists between reboots.

• Network Home Accounts: This is a type in which the user account and the user data exist on the server. This allows great flexibility of the user (as she can use any machine on the network) but carries with it high demands.


Defining a value in NFSHomeDirectory does not mean that the data is stored on the server. The value must be a network path for that to happen. The definition of /Users/name tells the workstation were to create the home folder, not the server. The attribute is just created and stored on the server.


What type of user account are you trying to create? I think we've gotten away from the original discussion.


Reid

Apple Consultants Network

Author "Yosemite Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Nov 12, 2014 11:23 AM in response to Strontium90

Thanks for the reply. I know we're straying a bit from the question, but this is actually very helpful for me. I had done a bunch of research on the proper account types when I set up the network. The only part I didn't understand was that the home directory listed in a user profile was not necessarily ON the server, just that it had to be listed in the profile. I had set everyone up as Services Only because that fit what I was originally looking to do. The only reason I want to enable Open Directory is because I want my users to be able to authenticate once on their computers so that they do not have to log in each time they access file shares and so that I can use the Google APIs and connect that authentication to our Google for Business account so they are logged in automatically to GMail on the website. That's why I hadn't assigned home directories - I didn't know I needed them for what I was doing.


So it looks like what I need are Mobile Cached Accounts, so that users with laptops can take them home and use them and then also use them when on our server. That way also if the server goes offline for some reason, the users can still access their own computers and do work. So I will try that on my test account and see if it allows me to log in both on and off network.


I know this is off-topic but would you then happen to know anything about integrating with Google Apps? I can start a new thread though, but this is the first time I've found someone with enough knowledge to actually help me through this setup. Thanks!

Nov 13, 2014 7:15 AM in response to JSP196

Yes. The only time the home folder is on the server is when you are using Network Home Folders. Or if you create the account as Local Only. Why Apple creates a home folder on the server when you do this I don't know. I too tend to create accounts as none - services only and then add the home folder path manually. If I have a lot of accounts, I import the records.


And I would agree. If you are supporting systems that are a blend of laptops and desktops, then mobile cached accounts is the most flexible. You get to centrally manage the accounts on the server, define password policy, and enforce use policy. The user is able to use the machine on or off the network as the credential is embedded in the device. And you get single sign on function. Keep in mind, this is dependent on your usage patterns. If you have an iMac user and she shuts down every day, then she will see the most benefit. Through longing window, she refreshes her experience with the server every day. Now, those laptop users who simple close the lid and go... They may not experience login windows for weeks or months. So the single sign on experience will not be the same.


As for the Google Apps. Check out this page. https://support.google.com/a/answer/106368?hl=en I don't do a lot with Google stuff so sadly I have no experience to share. However, Open Directory is LDAP. So in theory, this should work. This has been one of those items that is on my pile of things to explore but I simply have not had the need yet.


Glad to help. Good to see you are doing your homework and understanding the tech. Keep going.


Reid

Apple Consultants Network

Author "Yosemite Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Author "Mavericks Server – Control and Collaboration" :: Exclusively available in Apple's iBooks Store

Cannot log into OpenDirectory server

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.