Hello.

15.12.2008 18:26, Aaron Richton пишет:

On Mon, 15 Dec 2008, Alexey Lobanov wrote:

...

group of Debian servers. Everything works fine except userPassword, sambaLMPassword and sambaNTPassowrd attributes; the replicas (two of two) just don't have those attributes in any downloaded entries.

Are sambaLMPassword/sambaNTPassword visible on the slave cn=Subschema? (slapd -d config perhaps, too.)

The master and slave schemas are absolutely identical. Just rsynced. And the attributes are present in schema, because I can add them manually with an editor like Luma.

root@mail:/etc/ldap/schema# slapd -d config ..... reading config file /etc/ldap/schema/samba.schema ........ line 185 (attributetype ( 1.3.6.1.4.1.7165.2.1.24 NAME 'sambaLMPassword' DESC 'LanManager Password' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE ))

line 190 (attributetype ( 1.3.6.1.4.1.7165.2.1.25 NAME 'sambaNTPassword' DESC 'MD4 hash of the unicode password' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} SINGLE-VALUE ))

However, I am really surprised now. There is no "NAME 'userPassword'" definition in schema files, neither in master nor in slaves. More exactly, the definition in generic core.schema is commented out:

# system schema #attributetype ( 2.5.4.35 NAME 'userPassword' # DESC 'RFC2256/2307: password of user' # EQUALITY octetStringMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )

It looks like that this attribute definition is hardcoded in slapd. Correct?

Alexey

Hello.

15.12.2008 20:21, Quanah Gibson-Mount пишет:

And we can all try to guess and guess what's wrong. What would really help, is to know your configurations on the master & replica. Likely either an ACL or limit is blocking things on the master,

No it does not. The test was to connect master from slave machine using ldapsearch and *same* (copy'n'paste) credentials. The password hashes were displayed properly in ldapsearch output, and I wrote about it in my very first message. Is this test comprehensive or not?

Search limits are not set in master.

or your syncrepl config on your replica is incorrect.

The syncrepl config is trivial: no filters.

================== syncrepl rid=123 provider=ldap://ldap.office.rct-int type=refreshAndPersist interval=00:00:10:00 searchbase="dc=office,dc=rct-int" scope=sub schemachecking=on bindmethod=simple binddn="uid=syncuser,ou=People,dc=office,dc=rct-int" credentials="****" ====================

All (really all!) entries are replicated properly but none of them contains any userPassword, sambaLMPassword or sambaNTPassword attribute. It had been checked both via LDAP browser with rootdn binding and via slapcat output.

Actually, I hoped that someone in this list knows the nature of this problem already. In my understanding, it can be related either with hashed (vs. plaintext) attributes processing in syncrepl or with undocumented requirements to access rights (i.e., syncrepl binddn must have "write" rights instead of "read").

-- Alexey

Alexey Lobanov schrieb: [snipp]

Actually, I hoped that someone in this list knows the nature of this problem already. In my understanding, it can be related either with hashed (vs. plaintext) attributes processing in syncrepl or with undocumented requirements to access rights (i.e., syncrepl binddn must have "write" rights instead of "read").

I would remove all ACLs or put a "... by * write" in front for testing and see if it helps. FWIW, we're running 2.3.x as a slave against 2.2.x from a certain Vendor and I failed to get refreshAndPersist working but refreshOnly works.

cheers Paul