LDAP replication works - but user passwords are missing
We created a master / slave environment, where a ldap server replicates another periodically. All entries are replicated correctly, but the attribute 'userPass' is not replicated. We assumed this is an ACL issue, so on the master side we added
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read
but the userPass is still missing.
To debug this step-by-step, it would be helpful
Is there a tool that helps me checking ACL issues? So i could impersonate a user and check an attribute?
What logging level on the server side would display ACL issues?
Whenever we try ldapmodify changes on the slave side, they are rejected with 'shadow context', which is pretty logical, but how can we make changes? Do we have to exclude the cn=config from replicating
Since any changes on the slave side are rejected, how do we stop replication mode at all?
ldap openldap replication
edited Feb 25 at 18:21
473183469
979617
asked Feb 13 at 11:55
HeinerHeiner
31
migrated from superuser.com Feb 13 at 12:53
This question came from our site for computer enthusiasts and power users.
add a comment |
We created a master / slave environment, where a ldap server replicates another periodically. All entries are replicated correctly, but the attribute 'userPass' is not replicated. We assumed this is an ACL issue, so on the master side we added
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read
but the userPass is still missing.
To debug this step-by-step, it would be helpful
Is there a tool that helps me checking ACL issues? So i could impersonate a user and check an attribute?
What logging level on the server side would display ACL issues?
Whenever we try ldapmodify changes on the slave side, they are rejected with 'shadow context', which is pretty logical, but how can we make changes? Do we have to exclude the cn=config from replicating
Since any changes on the slave side are rejected, how do we stop replication mode at all?
ldap openldap replication
edited Feb 25 at 18:21
473183469
979617
asked Feb 13 at 11:55
HeinerHeiner
31
migrated from superuser.com Feb 13 at 12:53
This question came from our site for computer enthusiasts and power users.
add a comment |
We created a master / slave environment, where a ldap server replicates another periodically. All entries are replicated correctly, but the attribute 'userPass' is not replicated. We assumed this is an ACL issue, so on the master side we added
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read
but the userPass is still missing.
To debug this step-by-step, it would be helpful
Is there a tool that helps me checking ACL issues? So i could impersonate a user and check an attribute?
What logging level on the server side would display ACL issues?
Whenever we try ldapmodify changes on the slave side, they are rejected with 'shadow context', which is pretty logical, but how can we make changes? Do we have to exclude the cn=config from replicating
Since any changes on the slave side are rejected, how do we stop replication mode at all?
ldap openldap replication
edited Feb 25 at 18:21
473183469
979617
asked Feb 13 at 11:55
HeinerHeiner
31
We created a master / slave environment, where a ldap server replicates another periodically. All entries are replicated correctly, but the attribute 'userPass' is not replicated. We assumed this is an ACL issue, so on the master side we added
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {3}to attrs=userPassword by dn.base="cn=syncprov,dc=thedomain,dc=com" read
but the userPass is still missing.
To debug this step-by-step, it would be helpful
Is there a tool that helps me checking ACL issues? So i could impersonate a user and check an attribute?
What logging level on the server side would display ACL issues?
Whenever we try ldapmodify changes on the slave side, they are rejected with 'shadow context', which is pretty logical, but how can we make changes? Do we have to exclude the cn=config from replicating
Since any changes on the slave side are rejected, how do we stop replication mode at all?
ldap openldap replication
ldap openldap replication
edited Feb 25 at 18:21
473183469
979617
asked Feb 13 at 11:55
HeinerHeiner
31
edited Feb 25 at 18:21
473183469
979617
asked Feb 13 at 11:55
HeinerHeiner
31
edited Feb 25 at 18:21
473183469
979617
edited Feb 25 at 18:21
473183469
979617
edited Feb 25 at 18:21
473183469
979617
979617
asked Feb 13 at 11:55
HeinerHeiner
31
asked Feb 13 at 11:55
HeinerHeiner
31
asked Feb 13 at 11:55
HeinerHeiner
31
31
migrated from superuser.com Feb 13 at 12:53
This question came from our site for computer enthusiasts and power users.
migrated from superuser.com Feb 13 at 12:53
This question came from our site for computer enthusiasts and power users.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.
For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
If the ACL is correct, you should be able to see the userPassword.
Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.
(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)
You will need to completely initialise the slave again, this time with the userPasswords's.
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
Solved the ACL issue: theolcAccess: {3}to attrs=userPassword by ...was generally correct but had to be issued before the firstby * none
– Heiner
Feb 13 at 23:11
1
Please also note the mismatch betweenuserPasswordin the acl anduserPassin text. Is it a clerical mistake? If not, you need the attribute name to match.
– 473183469
Feb 25 at 12:35
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f953723%2fldap-replication-works-but-user-passwords-are-missing%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.
For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
If the ACL is correct, you should be able to see the userPassword.
Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.
(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)
You will need to completely initialise the slave again, this time with the userPasswords's.
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
Solved the ACL issue: theolcAccess: {3}to attrs=userPassword by ...was generally correct but had to be issued before the firstby * none
– Heiner
Feb 13 at 23:11
1
Please also note the mismatch betweenuserPasswordin the acl anduserPassin text. Is it a clerical mistake? If not, you need the attribute name to match.
– 473183469
Feb 25 at 12:35
add a comment |
You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.
For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
If the ACL is correct, you should be able to see the userPassword.
Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.
(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)
You will need to completely initialise the slave again, this time with the userPasswords's.
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
Solved the ACL issue: theolcAccess: {3}to attrs=userPassword by ...was generally correct but had to be issued before the firstby * none
– Heiner
Feb 13 at 23:11
1
Please also note the mismatch betweenuserPasswordin the acl anduserPassin text. Is it a clerical mistake? If not, you need the attribute name to match.
– 473183469
Feb 25 at 12:35
add a comment |
You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.
For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
If the ACL is correct, you should be able to see the userPassword.
Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.
(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)
You will need to completely initialise the slave again, this time with the userPasswords's.
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
You can simply check if the ACL is correct now by logging in with the credentials for the replication user and confirming that the userPassword gets displayed when you query other user objects.
For instance with a simple ldapsearch -D "cn=syncprov,dc=thedomain,dc=com" -w secret -p 389 -h server.example.com "cn=Heiner"
If the ACL is correct, you should be able to see the userPassword.
Fixing the ACL won't automatically start replicating the missing userPassword attributes to your slave.
(The changed ACL does not modify the original user account object, although cn=syncprov can now see an extra attribute, that is not a "new" attribute, on the master server that account remains unchanged. And since replication only synchronizes objects that have been updated nothing happens.)
You will need to completely initialise the slave again, this time with the userPasswords's.
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
answered Feb 13 at 13:44
HBruijnHBruijn
55.3k1089149
55.3k1089149
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
Solved the ACL issue: theolcAccess: {3}to attrs=userPassword by ...was generally correct but had to be issued before the firstby * none
– Heiner
Feb 13 at 23:11
1
Please also note the mismatch betweenuserPasswordin the acl anduserPassin text. Is it a clerical mistake? If not, you need the attribute name to match.
– 473183469
Feb 25 at 12:35
add a comment |
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
Solved the ACL issue: theolcAccess: {3}to attrs=userPassword by ...was generally correct but had to be issued before the firstby * none
– Heiner
Feb 13 at 23:11
1
Please also note the mismatch betweenuserPasswordin the acl anduserPassin text. Is it a clerical mistake? If not, you need the attribute name to match.
– 473183469
Feb 25 at 12:35
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
Did the check as suggested, and everything is displayed but 'userPass' does not show up, so at least it is clear it is an ACL issue. Thanks!
– Heiner
Feb 13 at 22:27
1
1
Solved the ACL issue: the
olcAccess: {3}to attrs=userPassword by ... was generally correct but had to be issued before the first by * none– Heiner
Feb 13 at 23:11
Solved the ACL issue: the
olcAccess: {3}to attrs=userPassword by ... was generally correct but had to be issued before the first by * none– Heiner
Feb 13 at 23:11
1
1
Please also note the mismatch between
userPassword in the acl and userPass in text. Is it a clerical mistake? If not, you need the attribute name to match.– 473183469
Feb 25 at 12:35
Please also note the mismatch between
userPassword in the acl and userPass in text. Is it a clerical mistake? If not, you need the attribute name to match.– 473183469
Feb 25 at 12:35
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f953723%2fldap-replication-works-but-user-passwords-are-missing%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
