Yosemite Server 4.0 bugs

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

If you get this far without solving the problem, then you'll need to examine the logs in the Open Directory section of the log list in the Server app, and also the system log on the clients.

This situation cause when we have server behind nat and server IP is 10.x.x.x, but server have DNS service that tell about our server has ip not 10.x.x.x

I am not quite sure what this means, but if the server name does not resolve for the clients, then you're failing at Step 2.

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

Is no longer valid on Yosemite. the /var/db/openldap/migration/.rekerberize 'flag' is no longer supported.

itux wrote:

Thanks, but i know this, and:

- This situation cause when we have server behind nat and server IP is 10.x.x.x, but server have DNS service that tell about our server has ip not 10.x.x.x

- In my situation i have NATed DNS, WEB, MAIL server on Mac, and it's all work as i need. But not OpenDirectory only, i can't use OD for provide external connect for authenticate my users from internet.

- Why i can't have NATed DNS server and OD together ?

- Or i need all service as only local or mac for perfect work need a real ip !

- And for external access you need a real static IP for Mac, not for NAT 🙂

Some services can be accessed via a NAT connection, that is a user out on the Internet can access a server hidden behind a NAT connection. Examples include Mail Server and Web Server. Some services could in theory also be accessed directly this way (even through a NAT connection) but should not be made available for security reasons, e.g. a company file server running either AFP or SMB. Some services like Open Directory should not be accessed this way both for security and DNS related issues.

Your Open Directory server should as previously stated have a static IP address and this should be on your LAN range. You should have a DNS server also running on your LAN which resolves the name of the Open Directory server to that static IP address that is within the LAN range. It is also necessary to have a working reverse DNS record and lookup, it is this later issue that makes it pretty much impossible to use public IP addresses and NAT connections.

So both for technical and security reasons the great unwashed out on the Internet should not be able to access your Open Directory server. This does not mean it is impossible to allow remote use users to access your Open Directory server, to do this you need to use a VPN setup, this can be either a site-to-site hardware VPN solution, or it can be a VPN server allowing individual remote users to connect. When the remote user connects it will be given an IP address that can connect to your LAN and - in this case you would also have your VPN server tell the remote user to use your own internal LAN based DNS server instead of a standard Internet based DNS server. The remote user will then be able to talk directly to both your own DNS server and your Open Directory server without having to go through a NAT connection. It will then be able to do forward and reverse DNS lookups to talk to your Open Directory server.

Note: It is possible to use the same Domain Name both internally and externally this requires two DNS servers, one on your LAN (for internal use) and one outside, this is called a 'split horizon DNS setup'. Some people advise against this as you then have to be careful with how you handle some records, for example you need to remember to define on your internal DNS server the record for your possibly externally hosted web server so your own internal users can access your own website.