Hi All,
I have configured two servers with multi master replication. Below is my configuration for synrepl on both servers.
Server One ------------
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two --------------
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN on both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why the user is not able to login.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is my configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN on both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why the user is not able to login.
Rgds,
Aravind M D
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is my configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN on both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why the user is not able to login.
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Hi, thats pretty the same like copying the database. Because data and metadata are completely copied over from one host to the other. Please delete your db files completely on one master (backup first!) and let it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is my configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN on both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why the user is not able to login.
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
to do -- Sartre | Do be do be do -- Sinatra
Hi
I have deleted the db from one server and synced the db from the other. Now my contextCSN is same on both the system. But still in my log files it showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212db0 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa202b60 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than ours uid=user,ou=People,dc=example,dc=com ours 20100610110242.266299Z#000000#001#000000, new 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa1f8920 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212e88 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=sudhiryr,ou=People,dc=avasarala,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212cb8 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
Hi, thats pretty the same like copying the database. Because data and metadata are completely copied over from one host to the other. Please delete your db files completely on one master (backup first!) and let it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is
my
configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN
on
both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
identical
CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and
why
the user is not able to login.
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is
to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
Hey buddy,
havn't you seen some time around here.
I compared your slapd config to one of my own and to this one: https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see down at "LDAP Replication")
From that point I see you're using the same rid for both servers, so both
servers are in the ldap way are the "same" and that's a problem because the both DBs have to be unique even if they hold the same data. Please consider to change the rid on one of your servers and repeat the step to replicate the database. Maybe rid=000 to rid=001.
Bye.
On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi
I have deleted the db from one server and synced the db from the other. Now my contextCSN is same on both the system. But still in my log files it showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212db0 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa202b60 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than ours uid=user,ou=People,dc=example,dc=com ours 20100610110242.266299Z#000000#001#000000, new 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa1f8920 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212e88 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=sudhiryr,ou=People,dc=avasarala,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212cb8 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
Hi, thats pretty the same like copying the database. Because data and
metadata
are completely copied over from one host to the other. Please delete your db files completely on one master (backup first!) and let it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is
my
configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the servers in one server i was able to login but on another server i was not able to login with the same password. I have checked the contextCSN
on
both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
identical
CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and
why
the user is not able to login.
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is
to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
Hi,
Now i have changed the rid of one of my server, now both servers have unique rid and sid. After changing the rid i have deleted and db and replicated from the other. Now when i change the password of the user it says successfully changed. But when i try to login with that password i was not able to login. Below is my log files
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0xb67cdbf2 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9e513a0 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncprov_sendresp: to=001, cookie=rid=001,sid=001,csn=20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 18:25:16 mails slapd[30896]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 be_search (0) Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 uid=titus,ou=People,dc=avasarala,dc=com Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=titus,ou=People,dc=avasarala,dc=com) Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9f93d68 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncprov_matchops: skipping original sid 001 Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9f94880 20100610125516.236254Z#000000#001#000000
Can you please help me why i was not able to login with the new password.
Hey buddy,
havn't you seen some time around here.
I compared your slapd config to one of my own and to this one: https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see down at "LDAP Replication")
From that point I see you're using the same rid for both servers, so both servers are in the ldap way are the "same" and that's a problem because the both DBs have to be unique even if they hold the same data. Please consider to change the rid on one of your servers and repeat the step to replicate the database. Maybe rid=000 to rid=001.
Bye.
On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi
I have deleted the db from one server and synced the db from the other. Now my contextCSN is same on both the system. But still in my log files it showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212db0 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa202b60 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than ours uid=user,ou=People,dc=example,dc=com ours 20100610110242.266299Z#000000#001#000000, new 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa1f8920 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212e88 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=sudhiryr,ou=People,dc=avasarala,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212cb8 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
Hi, thats pretty the same like copying the database. Because data and
metadata
are completely copied over from one host to the other. Please delete your db files completely on one master (backup first!)
and
let it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to
the
other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below
is
my
configuration for synrepl on both servers.
Server One
serverID 001
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.100 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Server Two
serverID 002
overlay syncprov syncprov-checkpoint 100 10
syncrepl rid=000 provider=ldap://192.168.10.25 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked
in
the servers in one server i was able to login but on another server i
was
not able to login with the same password. I have checked the
contextCSN
on
both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add uid=user,ou=People,dc=example,dc=com (68) Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
identical
CSN uid=user,ou=People,dc=example,dc=com 20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files
and
why
the user is not able to login.
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche |
To
be is
to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
Hi,
I have no clue what the problem is in your configuration.
Did you really started with a blank backend database (bdb/hdb)? Did you read about the differences of replication type "RefreshOnly" or "RefreshAndPersist"?
Try to avoid changing replication settings while both hosts are replicating, this could have a strange impact on your database.
Bye and good luck.
On Thu, Jun 10, 2010 at 14:58, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi,
Now i have changed the rid of one of my server, now both servers have unique rid and sid. After changing the rid i have deleted and db and replicated from the other. Now when i change the password of the user it says successfully changed. But when i try to login with that password i was not able to login. Below is my log files
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0xb67cdbf2 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9e513a0 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncprov_sendresp: to=001, cookie=rid=001,sid=001,csn=20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 18:25:16 mails slapd[30896]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 be_search (0) Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 uid=titus,ou=People,dc=avasarala,dc=com Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=titus,ou=People,dc=avasarala,dc=com) Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9f93d68 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48 20100610125516.236254Z#000000#001#000000 Jun 10 18:25:16 mails slapd[30896]: syncprov_matchops: skipping original sid 001 Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing 0x9f94880 20100610125516.236254Z#000000#001#000000
Can you please help me why i was not able to login with the new password.
Hey buddy,
havn't you seen some time around here.
I compared your slapd config to one of my own and to this one: https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see
down
at "LDAP Replication")
From that point I see you're using the same rid for both servers, so both servers are in the ldap way are the "same" and that's a problem because the both DBs have to be unique even if they hold the same data. Please consider to change the rid on one of your servers and repeat the step to replicate the database. Maybe rid=000 to rid=001.
Bye.
On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi
I have deleted the db from one server and synced the db from the other. Now my contextCSN is same on both the system. But still in my log files it showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212db0 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa202b60 20100610110242.236793Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than ours uid=user,ou=People,dc=example,dc=com ours 20100610110242.266299Z#000000#001#000000, new 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=user,ou=People,dc=example,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa1f8920 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212e88 20100610110242.255828Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: do_syncrep2: cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical CSN uid=user,ou=People,dc=example,dc=com 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0) Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 uid=sudhiryr,ou=People,dc=avasarala,dc=com Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry unchanged, ignored (uid=user,ou=People,dc=example,dc=com) Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa212cb8 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878 20100610110242.266299Z#000000#001#000000 Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original sid 001 Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing 0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
Hi, thats pretty the same like copying the database. Because data and
metadata
are completely copied over from one host to the other. Please delete your db files completely on one master (backup first!)
and
let it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and slapadd, because of the change in contextCSN. I have not copied the database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to
the
other? Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran < aravind.divakaran@yukthi.com> wrote:
> Hi All, > > I have configured two servers with multi master replication. Below
is
my
> configuration for synrepl on both servers. > > Server One > ------------ > > serverID 001 > > overlay syncprov > syncprov-checkpoint 100 10 > > syncrepl rid=000 > provider=ldap://192.168.10.100 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=example,dc=com" > attrs="*,+" > bindmethod=simple > binddn="cn=syncuser,dc=example,dc=com" > credentials=password > > mirrormode TRUE > > Server Two > -------------- > > serverID 002 > > overlay syncprov > syncprov-checkpoint 100 10 > > syncrepl rid=000 > provider=ldap://192.168.10.25 > type=refreshAndPersist > retry="5 5 300 +" > searchbase="dc=example,dc=com" > attrs="*,+" > bindmethod=simple > binddn="cn=syncuser,dc=example,dc=com" > credentials=password > > mirrormode TRUE > > Today one of user said that he was not able to login. So i checked
in
> the > servers in one server i was able to login but on another server i
was
> not > able to login with the same password. I have checked the
contextCSN
on
> both server they are equal. In the log it is showing this > > syncrepl_entry: rid=000 entry unchanged, ignored > (uid=user,ou=People,dc=example,dc=com) > Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 > uid=user,ou=People,dc=example,dc=com > Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add > uid=user,ou=People,dc=example,dc=com (68) > Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
identical
> CSN uid=user,ou=People,dc=example,dc=com > 20100422132507.789242Z#000000#002#000000 > > Can anyone help me why above message is showing in the log files
and
why
> the user is not able to login. > > Rgds, > > Aravind M D > >
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche |
To
be is
to do -- Sartre | Do be do be do -- Sinatra
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
be is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
-- To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
I don't like having the /etc/ldap.conf world readable because then anyone who has shell access can see our general ldap login credentials (without which you cannot see anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!" problem because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to names from the ldap tree.
Advice?
On Mon, 14 Jun 2010, Ariel wrote:
I don't like having the /etc/ldap.conf world readable [...] Advice?
And you didn't chmod /etc/passwd and /etc/group too? What if people get valuable information out of those? You can't do this and be POSIX multi-user; getgr*/getpw* are unprivileged operations. Your users should be able to get some output with getent(1), and your users should be able to get the same output with "cat /etc/ldap.conf" and a bit of thought, and any attempts to make that harder will be a waste of time on your part. Change back the permissions, or change your OS.
Now, with all this said, if your users can get *more* information with "cat /etc/ldap.conf" and thought than getent(1) provides, that may well be a configuration error on your part, which would be appropriate to discuss on this list...
On Monday, 14 June 2010 17:03:29 Ariel wrote:
I don't like having the /etc/ldap.conf world readable because then anyone who has shell access can see our general ldap login credentials (without which you cannot see anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!" problem because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to names from the ldap tree.
Advice?
nss_ldap already caters to this, by the 'rootbinddn' option, and the /etc/ldap.secret file. If rootbinddn is used, then process which are running as root use this DN, and the password from the /etc/ldap.secret file (which can thus be protected from non-root users).
In order to make effective use of this, you probably need to run nscd (as root, thus it is able to contact the LDAP server as rootbinddn).
Of course, you need to consider: 1)The fact that users who would have access to credentials already have access to the information you are trying to protect 2)The identity you use for nss_ldap should be least-privilege in any case
Finally, you may also want to consider per-host credentials ... easiest in a Kerberos environment.
Did you read the nss_ldap documentation?
(Aaron already replied, but the fact that nss_ldap supports what you wanted originally was not covered).
Regards, Buchan
Buchan Milne wrote:
On Monday, 14 June 2010 17:03:29 Ariel wrote:
I don't like having the /etc/ldap.conf world readable because then anyone who has shell access can see our general ldap login credentials (without which you cannot see anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!" problem because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to names from the ldap tree.
Advice?
nss_ldap already caters to this, by the 'rootbinddn' option, and the /etc/ldap.secret file. If rootbinddn is used, then process which are running as root use this DN, and the password from the /etc/ldap.secret file (which can thus be protected from non-root users).
The rootbinddn is just usefull/used in case of privileged (e.g. password reset by root) operations (which is normally done by root) therefore the file system permissions of /etc/ldap.secret can (should!) be protected. rootbinddn and /etc/ldap.secret have no effect on standard nss operations invoked by unprivileged users.
In order to make effective use of this, you probably need to run nscd (as root, thus it is able to contact the LDAP server as rootbinddn).
Of course, you need to consider: 1)The fact that users who would have access to credentials already have access to the information you are trying to protect 2)The identity you use for nss_ldap should be least-privilege in any case
I've a question in regard to the exactly representation of "least-privilege" (hardening of slapd) to operate with nss_ldap. But first let me try to summarize my investigations:
The problem I see is that [nss|pam]_ldap's configuration file /etc/ldap.conf needs to be world readable to support a directory listing like for example "ls -al /home" wherein all the uidNumbers get resolved into names (uid/cn).
In my opinion there are two kind of approaches in regard to slapd's privilege configuration (ACLs) which both result in nearly the same behavior:
1.) don't use a bindDn in /etc/ldap.conf and allow anonymous read in slapd (limited to posix account objectClass' attributes)
2.) use a bindDn in /etc/ldap.conf which also requires a "bindPw". Thus /etc/ldap.conf needs to be world readable this approach also results in some kind of "quasi-anonymous" access (in case a logged in user uses the bindDn/bindPw for his own experiments ;-))
To limit the possible side-effects (information disclosure) slapd's ACL settings need to be very restrictive but there are not many possibilities to further restrict queries without "damaging" the standard nss behavior (e.g. resolving uidNumber and so on).
Even in case the ACLs are strictly limited to deliver only posixAccount/shadowAccount relevant attributes, in most commonly ldap driven environments the nss|pam_ldap deployments disclose more security relevant information than the previous (non-ldap) /etc/passwd /etc/shadow approach:
Regardless whether approach 1.) or 2.) (which you are forced to in case your directory does not support anonymous binds - e.g. MS AD) is deployed a simple ldapsearch (anonymous or by use of bindDn/bindPw) delivers the /etc/passwd similar content to satisfy/achieve the unix system's standard nss behavior: "user:uidNumber:gidNumer:gecos: ...."
That's fine, but how about ldapsearch "+" (querying for operational attributes)?
By querying the operational attributes any interested user could get for example "helpful" additional information in comparison to /etc/passwd to narrow valuable attacks: - createTimestamp could be a good indicator for "old" and might be higher privileged users? - modifyTimestamp could be used to identify users who have not changed their passwords for years... - and many more ideas regarding the other operational attributes
Summary: In my opinion the only (theoretical?) chance left to further "harden" nss|pam_ldap deployments (by further restricting slapd's ACLs) is to suppress delivery of some operational attributes (for the nss|pam_ldap's proxy-user bindDn!) to a minimum.
I've (just for fun) already experimented with this. And all I can say nss|pam_ldap and slapd are still working fine but - and now let me come to the question:
I'm completely unsure whether suppressing operational attributes could harm slapd's internal operations in any kind? Ok thinking of denying contextCSN in replicated environments - hehe - the answer seems clear to me but what about the entryDN, hasSubordinates, and all the others... are they needed by slapd to operate correctly (possibly the operational attributes need is backend depending)?
Finally, you may also want to consider per-host credentials ... easiest in a Kerberos environment.
Using sasl external or kerberos in combination with nss|pam_ldap's /etc/ldap.conf does not seem to improve security: the certificate's key needs to be world readable so any interested user can take the key and the certificate to bind "-Y EXTERNAL" to investigate the posixAccount users (and - I'm not sure - the same should apply to kerberos system/server tickets which needs to be world readable, too).
Did you read the nss_ldap documentation?
(Aaron already replied, but the fact that nss_ldap supports what you wanted originally was not covered).
In my opinion that's not sure.
BTW and in regard to the "just for fun section", mentioned above: nss|pam_ldap has obvious design deficits therefore "nss_ldapd" has been developed and the related "slapo-nssov" is currently in development. These two approaches represent another level of indirection and seem to solve the above described general problems regarding the "quasi-anonymous" access because the nss part can be run in privileged user context where the bindDn/bindPw is probably kept more secure.
nss_ldapd seems to be quite stable. nssov is in the contrib branch of slapd and need to be compiled manually. Possibly one should give them a try instead of betting on a dead horse (nss_ldap)...
On Tuesday, 15 June 2010 09:01:13 Daniel wrote:
Buchan Milne wrote:
On Monday, 14 June 2010 17:03:29 Ariel wrote:
I don't like having the /etc/ldap.conf world readable because then anyone who has shell access can see our general ldap login credentials (without which you cannot see anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!" problem because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to names from the ldap tree.
Advice?
nss_ldap already caters to this, by the 'rootbinddn' option, and the /etc/ldap.secret file. If rootbinddn is used, then process which are running as root use this DN, and the password from the /etc/ldap.secret file (which can thus be protected from non-root users).
The rootbinddn is just usefull/used in case of privileged (e.g. password reset by root) operations (which is normally done by root) therefore the file system permissions of /etc/ldap.secret can (should!) be protected.
No, this is not the only reason for the rootbindd option. In this case, I have no binddn/bindpw (I usually use SASL):
Without rootbinddn, getent passwd as root: Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 ACCEPT from IP=127.0.0.1:58579 (IP=0.0.0.0:389) Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 BIND dn="" method=128 Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 RESULT tag=97 err=0 text= Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0 filter="(objectClass=posixAccount)" Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SEARCH RESULT tag=101 err=0 nentries=32 text= Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 closed (connection lost)
With rootbinddn, getent passwd as root:
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 ACCEPT from IP=127.0.0.1:37331 (IP=0.0.0.0:389) Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" method=128 Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" mech=SIMPLE ssf=0 Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 RESULT tag=97 err=0 text= Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0 filter="(objectClass=posixAccount)" Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SEARCH RESULT tag=101 err=0 nentries=32 text= Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 closed (connection lost)
rootbinddn and /etc/ldap.secret have no effect on standard nss operations invoked by unprivileged users.
Sure, but it *does* have an effect on any nss operations by a process running as root.
In order to make effective use of this, you probably need to run nscd (as root, thus it is able to contact the LDAP server as rootbinddn).
Of course, you need to consider: 1)The fact that users who would have access to credentials already have access to the information you are trying to protect 2)The identity you use for nss_ldap should be least-privilege in any case
I've a question in regard to the exactly representation of "least-privilege" (hardening of slapd) to operate with nss_ldap. But first let me try to summarize my investigations:
The problem I see is that [nss|pam]_ldap's configuration file /etc/ldap.conf needs to be world readable to support a directory listing like for example "ls -al /home" wherein all the uidNumbers get resolved into names (uid/cn).
By design, it should be world readable. If you want credentials to be protected, use rootbinddn and /etc/ldap.secret, and e.g. nscd to ensure lookups end up being done by root.
In my opinion there are two kind of approaches in regard to slapd's privilege configuration (ACLs) which both result in nearly the same behavior:
1.) don't use a bindDn in /etc/ldap.conf and allow anonymous read in slapd (limited to posix account objectClass' attributes)
2.) use a bindDn in /etc/ldap.conf which also requires a "bindPw". Thus /etc/ldap.conf needs to be world readable this approach also results in some kind of "quasi-anonymous" access (in case a logged in user uses the bindDn/bindPw for his own experiments ;-))
3)Use rootbinddn and /etc/ldap.secret with nscd or similar, with or without binddn/bindpw.
To limit the possible side-effects (information disclosure) slapd's ACL settings need to be very restrictive but there are not many possibilities to further restrict queries without "damaging" the standard nss behavior (e.g. resolving uidNumber and so on).
Even in case the ACLs are strictly limited to deliver only posixAccount/shadowAccount relevant attributes, in most commonly ldap driven environments the nss|pam_ldap deployments disclose more security relevant information than the previous (non-ldap) /etc/passwd /etc/shadow approach:
Only if you use ldap for shadow ... if you don't, you will disclose less.
Regardless whether approach 1.) or 2.) (which you are forced to in case your directory does not support anonymous binds - e.g. MS AD
AD supports anonymous binds, but it is disabled by default, but then again SSL isn't available by default ...
) is deployed a simple ldapsearch (anonymous or by use of bindDn/bindPw) delivers the /etc/passwd similar content to satisfy/achieve the unix system's standard nss behavior: "user:uidNumber:gidNumer:gecos: ...."
That's fine, but how about ldapsearch "+" (querying for operational attributes)?
They are subject to ACLs, just like any other attributes.
By querying the operational attributes any interested user could get for example "helpful" additional information in comparison to /etc/passwd to narrow valuable attacks:
- createTimestamp could be a good indicator for "old" and might be
higher privileged users?
- modifyTimestamp could be used to identify users who have not changed
their passwords for years...
- and many more ideas regarding the other operational attributes
So, don't allow access to these attributes by your proxy DN or anonymous, in either of the 2 cases above.
Summary: In my opinion the only (theoretical?) chance left to further "harden" nss|pam_ldap deployments (by further restricting slapd's ACLs) is to suppress delivery of some operational attributes (for the nss|pam_ldap's proxy-user bindDn!) to a minimum.
I've (just for fun) already experimented with this. And all I can say nss|pam_ldap and slapd are still working fine but - and now let me come to the question:
I'm completely unsure whether suppressing operational attributes could harm slapd's internal operations in any kind? Ok thinking of denying contextCSN in replicated environments - hehe - the answer seems clear to me but what about the entryDN, hasSubordinates, and all the others... are they needed by slapd to operate correctly (possibly the operational attributes need is backend depending)?
'Needed by slapd to operate' is orthogonal to 'needed by nss_ldap to operate'.
Finally, you may also want to consider per-host credentials ... easiest in a Kerberos environment.
Using sasl external or kerberos in combination with nss|pam_ldap's /etc/ldap.conf does not seem to improve security: the certificate's key needs to be world readable
Not necessarily.
so any interested user can take the key and the certificate to bind "-Y EXTERNAL" to investigate the posixAccount users (and - I'm not sure - the same should apply to kerberos system/server tickets which needs to be world readable, too).
Not necessarily. See 'use_sasl' and 'root_use_sasl' options. If users are getting tickets on login, and you have 'use_sasl', user lookups will use their own privileges (if you have appropriate mapping from the SASL identity to their DN on the LDAP server).
Did you read the nss_ldap documentation?
(Aaron already replied, but the fact that nss_ldap supports what you wanted originally was not covered).
In my opinion that's not sure.
BTW and in regard to the "just for fun section", mentioned above: nss|pam_ldap has obvious design deficits therefore "nss_ldapd" has been developed and the related "slapo-nssov" is currently in development. These two approaches represent another level of indirection and seem to solve the above described general problems regarding the "quasi-anonymous" access because the nss part can be run in privileged user context where the bindDn/bindPw is probably kept more secure.
But, using nscd with nss_ldap achieves the same. Now, using nscd (or, maybe nss_ldap with nscd ...) does come with its own issues ...
nss_ldapd seems to be quite stable. nssov is in the contrib branch of slapd and need to be compiled manually. Possibly one should give them a try instead of betting on a dead horse (nss_ldap)...
But, the privilege issue isn't the biggest reason.
Regards, Buchan
On 10/06/2010 14:58, Aravind Divakaran wrote:
Hi,
Now i have changed the rid of one of my server, now both servers have unique rid and sid. After changing the rid i have deleted and db and replicated from the other. Now when i change the password of the user it says successfully changed. But when i try to login with that password i was not able to login. Below is my log files
Are you sure that the ACLs allow the replication user to read the userPassword attribute? And, of course, bind using it?
Jonathan
Hi
Now the problem is resolved. While i was trying to debug i have noticed that when changing the password using ldappasswd command i was able to login. But when i am changing the password using a php frontend it is not allowing me to login again with the new password. Problem will happen only when i am using any special characters in the new password. So i created a new interface in python for changing the ldap password. Now everything is working fine.
I am very much thankful for all the people in the mailing list who helped me to debug and solve my issue.
On 10/06/2010 14:58, Aravind Divakaran wrote:
Hi,
Now i have changed the rid of one of my server, now both servers have unique rid and sid. After changing the rid i have deleted and db and replicated from the other. Now when i change the password of the user it says successfully changed. But when i try to login with that password i was not able to login. Below is my log files
Are you sure that the ACLs allow the replication user to read the userPassword attribute? And, of course, bind using it?
Jonathan
Jonathan Clarke - jonathan@phillipoux.net
Ldap Synchronization Connector (LSC) - http://lsc-project.org
Rgds,
Aravind M D
openldap-technical@openldap.org
-
Aaron Richton -
Aravind Divakaran -
Ariel -
Benjamin Griese -
Buchan Milne -
Daniel -
Jonathan Clarke