Lion Server problem - Computer is already a network directory server

• Correct DNS?

  Forward & reverse mappings?

• Delete the necessary keys in the system keychain?

  When you do this are you running Keychain Access on the actual server or an administrative desktop? See my earlier comments about ensuring you're on the right machine (Re: Lion Server problem - Computer is already a network directory server)

• Run Keychain FirstAid in Keychain Access

These are the things that all here have found to be the cause/remedy to this issue.

I'm at a loss.

DNS is fine.

Mappings are resolving correctly.

I'm sitting on the server running Keychain I've deleted everything that relates to my server but still I get the same error. Run FirstAid and even that tells me everything is A OK.........

I really do want to avoid a reinstall but at the moment it seems likely?

Had the same problem. Turned out that CA directory had to be removed from:

/var/root/Library/Application Support/Certificate Authority

fzawadiak, thank you for your last response. I tried everything with no fix, until I removed the folder in /var/root/Library/Application Support/Certificate Authority.

Thank you SOO much! This was a real headache for me, and this cleared it right up. Now i'm back to getting the profilemanager running again as it says it is disabled, even though it is enabled. Cracked that nut before....

WHOLEY MOLEY! THAT WORKED.

Get into that /var/root/Library/Application Support/Certificate Authority

..and delete every one of those MoFos!

Recap :

If for some reason you have LDAP error -14006 or problem with LDAP state "Not running" :

1) Remove Certificate used by LDAP from the Keychain as well as :

IntermediateCA_hostname

OPENDIRECTORY_ROOT_CA_IDENTITY

OPENDIRECTORY_INT_CA_IDENTITY

MACHINE_IDENTITY

2) sudo rm -R /var/root/Library/Application\ Support/Certificate\ Authority/

Many thanks to fzawadiak

Summary:

How to fix Open Directory after Changing your Server's Hostname (see separate post)

Problem:

I had to change our server's hostname from a private hostname (server.name.private) to a public hostname (name.dyndns.org).

Procedure:

1. Precautions:

Since I was anticipating major dramas I tested the change of hostname on a clone ( I used Super Duper, and I very strongly advise everybody to heed this warning because a change of hostname will corrupt your server services, in particular Open Directory)

Second, I exported the network users from Server Admin and copied the archive to the Drop Folder of the server's local account (because the network accounts will be unavailable after demoting the OD Master.)

2. Change hostname and demote OD Master

a) I re-booted the server from the clone

b) I changed the hostname in Server App and I noticed that the Open Directory Password and the Kerberos database were still stuck with the old hostname.

c) I then demoted to a standalone directory (Server Admin) and I tried to promote the server to an OD Master using the Server App (Manage Network Accounts). Server App always returned an error saying I should check my network settings.

3. List of 'fixes'

I tried the following fixes to no avail (which does not mean that you can skip them)

a) I checked the DNS entries, forward and reverse were working fine (sudo checkip -changehostname)

b) Checked with Lookup in Network Utility, all was fine

c) I deleted all system certificates (Keychain) which showed the name of the previous hostname

( N.B. you need not delete email certificate and private/public keys)

d) I tried to assign a new static IP in Networking Preferences (had no visible result)

e) I re-booted from the working drive and I re-paired permissions on the clone; I ran disk repairs.

Despite all this I could not re-create an OD Master.

I then looked for this dubious folder /var/root/Library/Application Support/Certificate Authority.

I could not find this folder when using the Finder's Go To Folder, nor did "Easy Find" see this folder.

I was about to give up when I read the posts on this page and I entered the Terminal commands

sudo rm -R /var/root/Library/Application\ Support/Certificate\ Authority/

I had not much hope when I set about to re-create the OD Master from the Server App.

But lo and behold !!! I did not trust my eyes when Server App claimed that the OD Master had been successfully created. And indeed, Server admin showed a running OD Master, LDAP, Kerberos and Password Server all running again !

Final touch: re-import the user accounts.

Epilogue:

I woud not have been able to fix this issue had not so many others shared their experience and the working solution.

Thank you all !

Let's hope that Apple will fix this annoying issue in the next server update.

Regards,

Twistan

I had the same problem. I looked at the OD's Configuration-Log and found one interesting entry:

2013-11-29 18:29:46 +0000 Creating admin user

2013-11-29 18:29:48 +0000 Creating certificate authorities & hostname certificate

2013-11-29 18:29:49 +0000 Creating root CA with COBA Open Directory-Zertifizierungsstelle

2013-11-29 18:29:49 +0000 ***Error creating domain CA. Error - The specified item already exists in the keychain.

2013-11-29 18:29:49 +0000 Root CA creation failed with error - -25299

However - I couldn't find anything in Keychain?!

I opened Terminal and did a sudo find / -name *Zertifizierungsstelle* and was really surprised that I found 2 directories still containing the certificates for the former root-ca and intermediate-ca at /private/var/root/Library/Application Support/Certificate Authority/

And from there there were 2 subdirectories containing the mentioned certificates.

I removed the 2 subdirectories and gave it another try - tata 🙂

sudo rm -R /var/root/Library/Application\ Support/Certificate\ Authority/

After a long couple of days, and a little more grey hair. (What I didn't pull out) This resolved my issue as well.

Thank you, fzawadiak