Shadow apple-xmlplist for cn=passwordserver,cn=config in LDAP

Originator:yoann.gini
Number:rdar://19840157 Date Originated:15-Feb-2015 11:11 AM
Status:Open Resolved:
Product:OS X Server Product Version:10.9+
Classification:Serious bug Reproducible:Always
 
Summary:
Since a while now, PasswordServer preferences are stored in the LDAP server. So when we need to update those settings, for example to use the ExternalCommand standard feature, we need to edit the preference via the LDAP server.

Since 10.9, this system is broken. I don't know how is it possible but the LDAP server has an inconsistant behavior with LDAP request concerning apple-xmlplist on cn=passwordserver,cn=config.

Depending of the LDAP request, if the attribute is specified as the only thing we want, the returned value is not the same as the full record.

This lead to a big problem since it's impossible to edit the shadow record. When we try to add the good content to the full record, it's still not return by the specific LDAP request.

Steps to Reproduce:
- Setup a standard OS X Server on 10.9 or 10.10 and enable correctly the OD service
- With directory service app, look at the passwordserver record on the LDAP server, the apple-xmlplist field is missing
- with the CLI, execute this LDAP search:
ldapsearch -x -b "cn=passwordserver,cn=config,dc=srv,dc=example,dc=com"
the apple-xmlplist field is missing
- with the CLI, execute this LDAP search:
ldapsearch -x -b "cn=passwordserver,cn=config,dc=srv,dc=example,dc=com" apple-xmlplist
the apple-xmlplist field is present with the default content
- with the CLI, re execute this LDAP search:
ldapsearch -x -b "cn=passwordserver,cn=config,dc=srv,dc=example,dc=com"
the apple-xmlplist field is still missing

If you try to modify the LDAP record to add the apple-xmlplist field, the record is saved, but not returned by the LDAP request without the attribute specifier.

Expected Results:
The LDAP request must be consistent and return the same content for each request

Being able to modify the apple-xmlplist field is mandatory for almost all OS X Server deployment scenario. It's the only possibility to synchronise the internal directory service to an external cloud service provider like mail provider.

Actual Results:
All OS X Server setup using external cloud provider are locked in 10.8 for they OD Server

Version:
All OS X / OS X Server version since 10.9.0 / 3.0 to 10.10.2 (Version 14C109) / 4.0.3 (version 14S350)

Notes:
Please, take this problem with attention, it's a really big one who can lead to the end of OS X Server in tech-dependant SMB.

Without the ability to edit the ExternalCommand field we can't do really important feature like directory synchronisation, password complexity audit trail or password black list.

All companies need that nowadays.



Additional comments:
After investigation it seems that feature is now broken by design. The odusers_search_pwsprefs function in odusers overlay block all incoming request to return an hardcoded array.

It's wrong in so many ways and I hope it will be fixed as soon as possible.

What's the point of preferences if you can't chose them?!

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!