User profiles disappear after Open Directory service restart

Question

Georg_R Author

Level 1

10 points

User profiles disappear after Open Directory service restart

Hi there!

I have noticed strange (as I estimate it) behaviour of the Profile Manager service.

Setup:

- server with OS X 10.9.3 and Server 3.1.1 installed

- clean Open Directory setup

- one test user added to the Workgroup

Scenario 1:

OD and PM services are running, user profile created in PM. After OD is restarted the profile dissappears. The same behaviour is observed for group profiles, but never for the devices (or device groups) profiles.

Scenario 2:

OD and PM services are running, user profile created in PM. After server restart the profile is still where it should be.

I was able to recreate the situation three times on three different machines.

Is this a bug or normal logic in Server?

If it's a logic behaviour how is it possible to keep the user and group profiles when the OD service is restarted?

Thanks.

OS X Server

Posted on May 22, 2014 7:06 AM

Reply

Answer 1

COETech

Level 1

5 points

May 29, 2014 12:29 PM in response to Georg_R

I think this is related to what we see.

Go into the Profile Manager web interface and find the Group. Check under Members to see if they are listed. If not click the Reload/Refresh button for the group. This seems to force PM to read OD and finds the group members.

The problem seems to be that PM uses a query to find the members of the groups in OD, but this information isn't kept persistently in PM.

This means that if users are logging in to download user profiles, they won't see the profiles until an admin goes in and clicks the reload/refresh button for the group.

Reply

Answer 2

COETech

Level 1

5 points

May 30, 2014 2:31 PM in response to COETech

I've tried setting the User profile to Auto Download, what periodically happens is that PM will remove the User profile (it doesn't see that the user is in the group), but if you refresh/reload from the PM web interface that group, it will reinstall the profile.

Again seems to be a bug in that PM doesn't keep persistent info from OD on who is a member of a group.

Reply

Answer 3

MrHoffman

Level 10

148,219 points

May 30, 2014 3:48 PM in response to Georg_R

This isn't normal.

OS X Server 3.1.2 lists various Profile Manager fixes.

Verify DNS services, too:

sudo changeip -checkhostname

Launch Console.app and see if there are any relevant errors being logged, as well.

Reply

Answer 4

Georg_R Author

Level 1

10 points

Jun 1, 2014 11:45 PM in response to Georg_R

Hi everybody!

First of all thank you for your help.

I didn't have time to try the solutions with 3.1.1, because 3.1.2 became available for download.

After upgrade to 3.1.2 the problem has gone. I have tried several times already, now it behaves as supposed: you turn OD service off and then back on and the profiles are just at the same place as they were.

Reply

Answer 5

Georg_R Author

Level 1

10 points

Jun 3, 2014 12:31 AM in response to Georg_R

Today after an OD service restart the problem came back. The profiles dissappeared. I restarted the server itself as well as the PM service. When trying to start PM service the following message is repeated several times before it starts working:

serveradmin[2887]: NSURLConnection/CFURLConnection HTTP load failed (kCFStreamErrorDomainSSL, -9843)

sudo changeip -checkhostname shows everything is ok.

It looks like there is some problem with the Open Directory, cause replication stop working sometimes too (log entry form a replica):

Node: /LDAPv3/127.0.0.1, Module: AppleODClientPWS - unable to read Password Server response - socket error on socket fd 12: Resource temporarily unavailable (5205)

And then:

slapd[40176]: slap_client_connect: URI=ldap://tm.accidentlaw.ru:389 ldap_sasl_interactive_bind_s failed (-2)

slapd[40176]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

Reply

Answer 6

MrHoffman

Level 10

148,219 points

Jun 3, 2014 6:01 AM in response to Georg_R

The cited domain is incorrectly configured outside your network for this sort of thing, so I'll assume that you're using NAT and a parallel DNS server(s) inside your network. There should be references only to your internal DNS server(s) on your NAT'd network, and no references to any DNS servers off your NAT'd network.

OD doesn't look to be working, or isn't reachable, or is balking.

Check that the server certificate(s) in use are valid, current, and that they match the host name(s) in use for the server(s) you're working with.

Failing that and if running a master and this is connecting to a replica, I'd likely demote the OD replica and then re-promote it, as a test.

Have current OD and system backups before proceeding, etc.

Reply

Answer 7

Georg_R Author

Level 1

10 points

Jun 3, 2014 6:28 AM in response to MrHoffman

Correctly, we have external DNS and an internal one, which is the only available to the clients on the local network. The internal DNS server has the default gateway stated as the forwarding server. The local DNS server has both NS-record for the DNS-Server and A-records for both OD Master and OD Replica.

When trying to look up the domain name inside the local network the result is the following:

Trying "accidentlaw.ru"

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26211

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:

;accidentlaw.ru. IN ANY

;; ANSWER SECTION:

accidentlaw.ru. 10800 IN SOA accidentlaw.ru. admin.accidentlaw.ru. 2014051621 3600 900 1209600 300

accidentlaw.ru. 10800 IN NS mx.accidentlaw.ru.

accidentlaw.ru. 10800 IN MX 0 mx.accidentlaw.ru.

;; ADDITIONAL SECTION:

mx.accidentlaw.ru. 10800 IN A 192.168.0.5

Received 123 bytes from 192.168.0.5#53 in 157 ms

mx.accidentlaw.ru is the OD replica and tm.accidentlaw.ru is the master:

Trying "tm.accidentlaw.ru"

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26200

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:

;tm.accidentlaw.ru. IN ANY

;; ANSWER SECTION:

tm.accidentlaw.ru. 10800 IN A 192.168.0.91

;; AUTHORITY SECTION:

accidentlaw.ru. 10800 IN NS mx.accidentlaw.ru.

;; ADDITIONAL SECTION:

mx.accidentlaw.ru. 10800 IN A 192.168.0.5

Received 84 bytes from 192.168.0.5#53 in 77 ms

The certificates are valid. I have also tried to re-select them in the Server app.

I have also recreated replica a couple of weeks ago, but will give it another try a little later.

MrHoffman, do you think exporting users, recreating OD Master, importing users and recreating replicas can be a solution?

Reply

Answer 8

Georg_R Author

Level 1

10 points

Jun 3, 2014 6:38 AM in response to Georg_R

By the way, I have noticed that replica is experiencing some problems with replication process:

Jun 3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: CONNECTED(0x7f8fc8e110e0) searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

Jun 3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (32) No such object

Jun 3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrep2: rid=001 (32) No such object

Jun 3 12:56:18 mx.accidentlaw.ru slapd[53990]: do_syncrepl: rid=001 rc -2 retrying

Jun 3 12:57:18 mx.accidentlaw.ru slapd[53990]: slap_client_connect: URI=ldap://tm.accidentlaw.ru:389 ldap_sasl_interactive_bind_s failed (-2)

Jun 3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: client_connect failed (-1) - searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

Jun 3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1[done]: si_ld(0x0) Can't contact LDAP server (-1)

Jun 3 12:57:18 mx.accidentlaw.ru slapd[53990]: do_syncrepl: rid=001 rc -1 retrying

Jun 3 12:58:18 mx.accidentlaw.ru slapd[53990]: do_syncrep1: CONNECTED(0x7f8fc8d86340) searchbase(cn=authdata) URI(ldap://tm.accidentlaw.ru:389)

Doe sit mean all of these problems are coming from OD master?

Reply

Answer 9

Georg_R Author

Level 1

10 points

Jun 3, 2014 6:54 AM in response to Georg_R

Is it interrelated?

https://discussions.apple.com/thread/6310565

Reply