Re: could not config n-way multi-master because insufficient access
gtalk:freeespe...@gmail.com gtalk%3afreeespe...@gmail.com
On Mon, Jun 7, 2010 at 6:09 PM, Buchan Milne bgmi...@staff.telkomsa.netwrote:
On Monday, 7 June 2010 07:10:00 owen nirvana wrote:
my env is Debian squeeze, OpenLDAP 2.4.17( from packages.debian.org)
I create an OpenLDAP Server, and try to config N-Wat multi-master,
according to OpenLDAP Admin Guide.
i adding init.ldif file on the server , the following is the content
*dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
dn: olcDatabase={0}config,cn=config* *
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret*
and I get error --- insufficient access , even if I set acess to * by
*
write in slapd.conf
i know that. I want to give binddn an enough priviledge
my binddn is rootdn, cn=admin,dc=example,dc=org
*ldapadd -c -D cn=admin,dc=example,dc=org -x -w ${rootpw} -f init.ldif*
i think, the content about n-way configuration in guide is a howto , but
${passwd} should be replaced by mine
One of slapd.conf or this ldif is irrelevant. Only one of them can apply
at a
time. Please be careful to check how your slapd is being started (e.g.
whether
-f or -F flags are passed or not etc.).
actually, I don't understand what the guide said.
Maybe you need to read the guide more ...
Also, note that it is not a HOWTO, but documents how various aspects
work,
not necessarily just copy-and-paste examples to use without thinking ...
'
This sets up the config database:
* dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: secret*
the above configuration block could not be import in my computer, it is
said at the begin.
Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc.
with your actual ldap urls):
* dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 $URI1
olcServerID: 2 $URI2
olcServerID: 3 $URI3
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=$URI1 binddn=cn=config
bindmethod=simple credentials=secret searchbase=cn=config
type=refreshAndPersist retry=5 5 300 5 timeout=1
olcSyncRepl: rid=002 provider=$URI2 binddn=cn=config
bindmethod=simple credentials=secret searchbase=cn=config
type=refreshAndPersist retry=5 5 300 5 timeout=1
olcSyncRepl: rid=003 provider=$URI3 binddn=cn=config
bindmethod=simple credentials=secret searchbase=cn=config
type=refreshAndPersist retry=5 5 300 5 timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE*
Which DN did you bind as when trying to apply this LDIF? E.g., can you
supply
the ldapmodify commandline you used?
Note that according to your back-config extract above, you should have
bound as
cn=config, but you need to check whether you are using slapd.conf or
back-config
for configuration.
the configuration block seems conflict with the former, why should I
write
olcServerID: 1 $URI1 into LDAP Server if olcServerID: 1 is right,
and
why should I not write an entire configuration, but two configuration
file
which seems conflict separately.
If you are doing configuration replication, the different servers need to
be
able to identify which server ID belongs to them. The means for doing this
is
providing the URL, which the server will try and match to one of it's
listening addresses (e.g. -h option to slapd).
I have set up an unlimit previledge, why LDAP Server report insufficient
access. what previledge should be set.
Probably with good reason, which we can't determine without answers to the
questions above.
Regards,
Buchan
actually , I do dispatch the different serverID to every machine, but
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 $URI1
olcServerID: 2 $URI2
olcServerID: 3 $URI3
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1
in my opinion, the two blocks is two different entry, why to replace by the
former after writing the latter into LDAP Server.
Tool to covert from LDIF cn=config to slapd.conf?
Dear Folks, It is nice that the tools convert from slapd.conf to the LDIF configuration. Is there a tool that converts the other way round? I could write one, but I'd rather use an existing wheel if there is one. -- Nick Urbanik http://nicku.org 808-71011 nick.urba...@optusnet.com.au GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 I disclaim, therefore I am.
Re: Tool to covert from LDIF cn=config to slapd.conf?
--On Wednesday, June 09, 2010 6:14 PM +1000 Nick Urbanik nick.urba...@optusnet.com.au wrote: Dear Folks, It is nice that the tools convert from slapd.conf to the LDIF configuration. Is there a tool that converts the other way round? I could write one, but I'd rather use an existing wheel if there is one. No. You're not supposed to go backwards in development. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: pam_ldap doesn't bind SIMPLE for anonymous auth?
On Jun 7, 2010, at 3:50 AM, Buchan Milne wrote: Sure, but are you sure ldapsearch and pam_ldap are using the same password? If you *think* so, maybe you should check with a packet capture ... I did, and found that pam_ldap had altered the password prior to submittal. It turns out that for what it perceives as invalid user ids, it changes the password hash to 'INCORECT', mis-spelling and all. There was a problem with nsswitch/nscd which when resolved, the userid was valid and ldap worked fine. This is hardly useful behavior. I fail to understand why this particular approach is taken. Also on the other hand, comparing the logs I showed indicates that more logging would really help identify the problem. The failed BIND attempt is not logged, even at debug level 9, which is part of what confuses a person trying to understand the problem. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: pam_ldap doesn't bind SIMPLE for anonymous auth?
Jo Rhett jrh...@netconsonance.com writes: I did, and found that pam_ldap had altered the password prior to submittal. It turns out that for what it perceives as invalid user ids, it changes the password hash to 'INCORECT', mis-spelling and all. There was a problem with nsswitch/nscd which when resolved, the userid was valid and ldap worked fine. This is hardly useful behavior. I fail to understand why this particular approach is taken. I can tell you in general why a PAM module would do that. One of the security concerns discovered a while back in PAM-style systems is that one could tell from timing measurements whether or not the username one attempted was valid but you had the wrong password or whether the username was entirely invalid. That's because the second case would be rejected much faster than the first. This information disclosure vulnerability could then be used to further target brute-force password attacks and sometimes even to deduce e-mail addresses for spam targets and other purposes. Many PAM modules and PAM-using applications were therefore modified to never reject invalid users up-front. Instead, they would mangle the password into something that would (hopefully) never authenticate and then go through the authentication process, hopefully thereby causing the failure to take roughly the same length of time in both cases. -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/
Re: pam_ldap doesn't bind SIMPLE for anonymous auth?
On Jun 9, 2010, at 12:37 PM, Russ Allbery wrote: I can tell you in general why a PAM module would do that. One of the much faster than the first. This information disclosure vulnerability could then be used to further target brute-force password attacks and I understand that. I believe that my complaint about the logging problem is valid. If you look at the log excepts below, it appears that in one scenario no BIND attempt occurred. Logging it for success but not for failure in the logs (see where it skips right to send-ldap_result without logging the BIND attempt) tends to lead someone down the wrong road when debugging the problem. Jun 4 14:58:52 ldap-server slapd[5158]: = dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 14:58:52 ldap-server slapd[5158]: = check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched= text= Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text= Jun 4 15:02:54 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 15:02:54 ldap-server slapd[5158]: = check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn=uid=jrhett,ou=Users,dc=equinix,dc=com mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: uid=jrhett,ou=Users,dc=equinix,dc=com to uid=jrhett,ou=Users,dc=equinix,dc=com Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched= text= Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on: -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: pam_ldap doesn't bind SIMPLE for anonymous auth?
Jo Rhett wrote: On Jun 9, 2010, at 12:37 PM, Russ Allbery wrote: I can tell you in general why a PAM module would do that. One of the much faster than the first. This information disclosure vulnerability could then be used to further target brute-force password attacks and I understand that. I believe that my complaint about the logging problem is valid. If you look at the log excepts below, it appears that in one scenario no BIND attempt occurred. Logging it for success but not for failure in the logs (see where it skips right to send-ldap_result without logging the BIND attempt) tends to lead someone down the wrong road when debugging the problem. You're overlooking the obvious fact, which we repeat on these lists far too many times, that syslog is lossy and cannot be relied on as a debugging aid. There's a reason slapd has an explicit -d debug flag, distinct from the syslog flags. Your log excerpt here clearly shows that it's sending a reply to an operation with id op=2, so obviously some other operations have already occurred on this connection. (Since operation counters always start from 0.) Either they're missing from your log or you just didn't snip the right portion of the log. Either way, the fact that there's no Bind request in this snippet doesn't mean that the Bind request didn't occur, or that slapd didn't attempt to send it to syslog. Jun 4 14:58:52 ldap-server slapd[5158]: = dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 14:58:52 ldap-server slapd[5158]:= check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]:= acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]:= acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched= text= Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text= Jun 4 15:02:54 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 15:02:54 ldap-server slapd[5158]:= check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]:= acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]:= acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn=uid=jrhett,ou=Users,dc=equinix,dc=com mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: uid=jrhett,ou=Users,dc=equinix,dc=com to uid=jrhett,ou=Users,dc=equinix,dc=com Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched= text= Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on: -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
