Currently Being ModeratedMar 14, 2013 11:04 AM (in response to finisherr)
Some more stuff I've done:
- So, in the certificates pane I made sure to assign Open Directory to the self-signed SSL certificate I made.
- I ran kinit principal_of_the_network_user from the client machine and actually got a ticket so it looks like Kerberos is working okay?
Currently Being ModeratedMar 14, 2013 11:59 AM (in response to finisherr)
It looks like the bound client computer doesn't want to check the custom search path for the shared directory domain provided by the Open Directory server when authenticating at the login window. If it did check the Open Directory domain, I would think that it would recognize the test user instead of reporting the error "Unknown user "test" at login attempt Passed for auditing." Is there any way that I can get the search path to recognize my Open Directory domain?
In Directory Utility I've selected Search Policy > Authentication > Custom Path where the path is /LDAPv3/name_of_the_fully_qualified_domain_name
I've actually set this up at home (with a different fully qualified domain name) in an environment without a firewall and got the same results. Very stumped.
Currently Being ModeratedMar 17, 2013 3:48 PM (in response to finisherr)
From the client comptuer did the following:
- ran dscl -u diradmin -p FQDN_of_Open_Directory_Server
- Once in interactive mode, I navigated down to the Users folder within the LDAPv3 node
- ran -authonly test password_for_test_account
- ran exit
The results came back positive--that is to say, there was no error output. So, this means that I can authenticate to the account just fine. It's just that the client machine doesn't recognize LDAPv3 in the search path (or at least I think) so I still can't log into the test accout at the login window.
Currently Being ModeratedMar 17, 2013 11:46 PM (in response to finisherr)
Some more information for you. I checked opendirectoryd.log. This was the interesting output:
2013-03-18 02:37:35.575905 EDT - 26.18 - Client: opendirectoryd, UID: 0, EUID: 0, GID: 0, EGID: 0
2013-03-18 02:37:35.575905 EDT - 26.18, Module: AppleODClientLDAP - unable to open connection to LDAP server - unable to create connection context
Currently Being ModeratedMar 19, 2013 12:13 PM (in response to finisherr)
I checked Directory Utility help. It indicated that the Computer ID shouldn't have hyphens in it. Of course mine did. I rebound the client machine with the new computer id with no success.
Just when I thought I was on to something...
Currently Being ModeratedMar 21, 2013 7:57 PM (in response to finisherr)
I figured it out. My original goal is to have Open Directory only for authentication, with home directories on the client machine. I thought that selecting Services Only would achieve this...I was wrong. So, I destroyed my Open Directory Master and started from scratch, except this time I turned on File Sharing and also selected a location for the home directory. It's working like a charm now.
Hopefully there is a way to set up Open Directory for authentication only.
Currently Being ModeratedMar 22, 2013 8:13 AM (in response to finisherr)
If you use services only at the cliet side then you can. At least how I understand what you're saying. For instance, if you create a standard client system user account and then go to System Preferences > Mail, Contacts & Calendars and add an OS X Server account there… that will only use services, plus file sharing services authentication, as defined by Server.app. This is in fact the simplest way to use OS X Server at the client side.
Basically the moment you want OS X Server and OD to know anything about a user's home directory then you have to do more.