RE: Slave not able to update master pwdFailureTime via chain.
by serpent6877
Anyone else have an answer for this?
Thanks,
Brad
-------- Original message --------
From: Brad dameron <serpent6877(a)hotmail.com>
Date:03/24/2014 8:36 AM (GMT-08:00)
To: Esteban Pereira <esteban.pereira(a)gepsit.fr>,openldap-technical(a)openldap.org
Subject: RE: Slave not able to update master pwdFailureTime via chain.
>From what I read I need to setup authzTo. But having problems understanding what I need to set in the slaps.conf and on the allowed user.
-------- Original message --------
From: Esteban Pereira <esteban.pereira(a)gepsit.fr>
Date:03/20/2014 10:55 AM (GMT-08:00)
To: Brad dameron <serpent6877(a)hotmail.com>,openldap-technical(a)openldap.org
Subject: Re: Slave not able to update master pwdFailureTime via chain.
I've never configured this kind of architecture, but as far as I know the
ppolicy, I think my first thought configuring this would have been to not
rebind as user because the attribute modified is an operational one which
need the manage right (not sure about that)
So I should have configured this with the replication user with manage
right and without rebinding as a user when chaining to the master.
Hope this help
On Thu, Mar 20, 2014 at 6:14 PM, Brad dameron <serpent6877(a)hotmail.com>wrote:
> I understand what you are saying. But this is what the
> ppolicy_forward_updates says:
>
> ppolicy_forward_updates
> Specify that policy state changes that result from Bind operations (such as recording
> failures, lockout, etc.) on a consumer should be forwarded to a master instead of
> being written directly into the consumer’s local database. This setting is only use‐
> ful on a replication consumer, and also requires the updateref setting and chain
> overlay to be appropriately configured.
>
> So when a password failure occurs "pwdFailureTime" it relays it to the master as the user doing a MOD
> from what I have seen in my logs. And thus the user doesn't have access to modify this attribute.
>
> Brad
>
>
>
> ------------------------------
> Date: Thu, 20 Mar 2014 12:13:02 +0100
> Subject: Re: Slave not able to update master pwdFailureTime via chain.
> From: esteban.pereira(a)gepsit.fr
> To: serpent6877(a)hotmail.com
> CC: openldap-technical(a)openldap.org
>
>
> Hi Brad,
>
> pwdFailureTime is an operational attribute, I don't think any user can
> modify it on any instance. May be you should try to modify it on the master
> to see if it comes from this assumption.
>
> Esteban
>
>
> On Thu, Mar 20, 2014 at 11:33 AM, Brad dameron <serpent6877(a)hotmail.com>wrote:
>
> OpenLDAP 2.4.23-26 on CentOS 5. I am trying to get the pwdFailureTime
> updated on the master when the slave recieves a password failure. Here is
> my config. It's pretty simple and basic. No TLS.
>
> Master:
>
> access to attrs=userPassword
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" read
> by self write
> by anonymous auth
> by * none
> access to *
> by group.exact="cn=ldapadmins,ou=Groups,dc=test,dc=net" write
> by dn.exact="cn=replication,dc=test,dc=net" write
> by self write
> by users read
> by anonymous read
> by * none
>
>
>
> Slave:
>
> overlay chain
> chain-uri ldap://172.16.0.84:389
> chain-rebind-as-user TRUE
> chain-idassert-bind bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> mode="self"
> chain-return-error TRUE
>
> # Password Policy
> overlay ppolicy
> ppolicy_default "cn=default,ou=Policies,dc=test,dc=net
> ppolicy_use_lockout
> ppolicy_forward_updates
>
>
> # Slave Replication
> syncrepl rid=101
> provider=ldap://172.16.0.84:389
> type=refreshAndPersist
> interval=00:00:01:00
> retry="60 10 300 +"
> searchbase="dc=test,dc=net"
> schemachecking=off
> bindmethod=simple
> binddn="cn=replication,dc=test,dc=net"
> credentials="MyPasswd"
> updateref "ldap://172.16.0.84:389"
>
>
>
> I see the connection on the master but it gives a permission error:
>
>
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> dn="cn=testuser,ou=People,dc=test,dc=net"
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 MOD
> attr=pwdFailureTime
> Mar 20 09:47:46 LDAP-RADIUS-1 slapd[14288]: conn=1124 op=3 RESULT tag=103
> err=50 text=
>
>
> I read that you maybe need authzTo added to the binddn for the chain? Or
> is this only for TLS?
>
> I tried adding this ldif:
>
> dn: cn=replication,dc=test,dc=net
> changetype: modify
> add: authzTo
> authzTo: *
>
> And even set the:
>
> chain-idassert-authzFrom "*"
>
> in the chain. But it always gives me the error code 50 not enough
> permissions. I believe it is supposed to give access to the user to MOD the
> pwdFailureTime tribute knowing it is coming from a relay. But I can't find
> very specific docs on this or see what is wrong. Any help apreciated.
>
> Thanks,
> Brad
>
>
>
8 years, 8 months
openldap for fedora
by Brendan Kearney
i hope to be getting some new machines and updating/upgrading my ldap
instances in the process. i am looking to use the ltb-project.org rpms
for the install, but have a couple of questions.
first, i do not see any fedora versions in the repo. only redhat 5 and
6. are these packages binary compatible with fedora?
second, it seems that the packages use the Sys V Init style, as i am
sure the RH servers still use. although that is supported for legacy
compatibility in fedora, does the new systemd init style work with these
packages?
third, is a package for fedora versions available through the
ltb-project site?
thank you,
brendan
8 years, 8 months
Why "ldapadd -x -D cn=admin, cn=config -W -f ~/sudoWork/cn\=sudo.ldif" does not work?
by Peng Yu
Hi,
I followed the following instructions.
http://ubuntuforums.org/showthread.php?t=1421998
I get the following error.
pengy@openldapserver:~$ ldapadd -x -D cn=admin,cn=config -W -f
~/sudoWork/cn\=sudo.ldif
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
Here is the log. Does anybody know what the log means and how to fix
the problem? Thanks.
pengy@openldapserver:~$ tail -n 5 /var/log/syslog
Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 ACCEPT from
IP=127.0.0.1:47481 (IP=0.0.0.0:389)
Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 BIND
dn="cn=admin,cn=config" method=128
Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=0 RESULT
tag=97 err=49 text=
Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 op=1 UNBIND
Mar 28 22:20:07 openldapserver slapd[972]: conn=1460 fd=21 closed
--
Regards,
Peng
8 years, 8 months
Re: What is the default of `-b`?
by Peng Yu
How to search for everything in the ldap database (such config)?
On Fri, Mar 28, 2014 at 8:31 AM, Brad Hartlove
<bradley.hartlove(a)g2-inc.com> wrote:
> Peng
>
> The default of "-b" should be whatever you have specified in your
> ldap.conf configuration file. In a fresh install, without any
> configuration, I do not believe it will look for any base. The "-b" flag
> is used to specify the base of the tree from where you wish to begin your
> search. If you also pass the "-v" flag, it will spit out the base you are
> using ex:" # base <dc=somedomain,dc=com> with scope subtree". In the
> ldap.conf (typically located in your /etc/opendlap directory in linux),
> the directive you want to set is "BASE". It natively comes with something
> that is commented out ex: #BASE dc=example,dc=com. You need to
> uncomment and add the appropriate base location from where you wish to
> operate. Bear in mind that this affects the behavior of all your OpenLDAP
> client calls if the "-b" is not specified in the command string.
>
> Regards,
> Brad Hartlove
>
> -----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Peng Yu
> Sent: Thursday, March 27, 2014 4:17 PM
> To: openldap-technical(a)openldap.org
> Subject: What is the default of `-b`?
>
> Hi,
>
> The man page says the following.
>
> `-b` *searchbase*
> : Use *searchbase* as the starting point for the search instead of
> the default.
>
> I'm wondering what is the default. If I don't specify -b, I will get an
> error. Does anyone know how show all the contents from the database?
> Thanks.
>
> $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
> dn: cn=config
>
> dn: cn=module{0},cn=config
>
> dn: cn=schema,cn=config
>
> dn: cn={0}core,cn=schema,cn=config
>
> dn: cn={1}cosine,cn=schema,cn=config
>
> dn: cn={2}nis,cn=schema,cn=config
>
> dn: cn={3}inetorgperson,cn=schema,cn=config
>
> dn: olcBackend={0}hdb,cn=config
>
> dn: olcDatabase={-1}frontend,cn=config
>
> dn: olcDatabase={0}config,cn=config
>
> dn: olcDatabase={1}hdb,cn=config
>
> $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// dn No such object (32)
>
> --
> Regards,
> Peng
--
Regards,
Peng
8 years, 8 months
Re: memberof in openldap
by Howard Chu
Brad Hartlove wrote:
> I get everything you said. I also understand that this may be a valid
> permissions issue. If the answer is "it isn't supposed to be done and the
> server will prevent that", that is what I will go with. This is not my
> first dance, but if I already knew every detail of LDAP's code, I wouldn't
> be on this mailing list.
There is no such thing as "LDAP's code" - LDAP is a protocol definition built
on a data model. There is "OpenLDAP code" and "SunDS code" etc., various other
implementations of the protocol and data model. It is well documented that
Sun/Netscape/RedHat/Microsoft implemented the specs incorrectly.
As I have said, I am seeing this defined in
> another LDAP's objectClass, so someone figured it out right, wrong, or
> indifferent. I am not here to argue, so if that is what I go with, so be
> it.
> Brad Hartlove
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: Friday, March 28, 2014 11:08 AM
> To: Michael Ströder; brad.hartlove(a)g2-inc.com;
> openldap-technical(a)openldap.org
> Subject: Re: memberof in openldap
>
> Michael Ströder wrote:
>> Brad Hartlove wrote:
>>> The core problem is why can I not add the operational attribute to my
>>> custom objectclass.
>>
>> Operational attributes are simply not normal user attributes.
>>
>> If your LDAP client is supposed to alter an attribute via LDAP it has
>> to be a user attribute. Period.
>
> That's only a partial answer.
>
> Brad, the answer is "go read the LDAP spec" - operational attributes are
> never part of any objectclass definition, and the server is free to use
> them in any entry regardless of objectclass.
>
> The OpenLDAP manpages are not here to teach you the basics of LDAP. You're
> expected to read the specs and know the basics of LDAP.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
8 years, 8 months
Syncrepl Multi-Master with multiple BDB backends
by Michael
I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a "replicate" user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement?
serverID 1 ldap://txeduds1
serverID 2 ldap://txeduds2
database bdb
suffix "dc=il,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=il,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.il
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=il,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com"
credentials=xxxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=nj,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=nj,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.nj
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=nj,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=ga,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=ga,dc=edu,dc=com"
rootpw xxx
directory /var/lib/ldap/ldap.edu.ga
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=ga,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
8 years, 8 months
cn=config replication mistake
by Ferenc Wagner
Hi,
First, please let me tell you the story of my adventure yesterday. I'll
summarize my questions at the end.
I've set up a simple master-slave replicated system some time ago (stock
Debian wheezy OpenLDAP, version 2.4.31-1+nmu2):
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=1 provider=ldap://elm.niif.hu [...]
dn: olcDatabase={1}mdb,cn=config
olcSyncrepl: {0}rid=2 provider=ldap://elm.niif.hu [...]
The slave opened two connections to the master, and everything worked
fine. Then I enabled TLS and put in a CNAME record, so that the master
became accessible as ldaps://ldap-master.niif.hu. I decided to also
switch over the replication traffic to the SSL channel, so ldapmodified
the above attributes to contain provider=ldaps://ldap-master.niif.hu.
This pretty much broke the system, because the master server suddenly
started to replicate from itself, thus became read-only.
Finding no other option, I stopped the "master" slapd and edited back
the providers to their previous values (above) in the
olcDatabase={0}config.ldif and olcDatabase={1}mdb.ldif files under the
cn=config directory of my server configuration. I know these files
should not be edited, but I found no other way.
This move made the master recognized itself again in the provider URI,
so it did not start replicating and became writeable. My edits,
however, did not propagate to the slave, probably because I did not
change the internal attributes (entryCSN?) so this was expected. Also,
slapcat started to report CRC warnings in some LDIF files while dumping
the databases, which was also understandable for the edited ones, but
not so much for cn=config.ldif (if I remember correctly).
I tried to fix these by doing some dummy changes by ldapmodify to the
database entries. For both, I added an extra olcAccess attribute, then
deleted it. These operations made the slave switch back its syncrepl
connections to the ldap port from ldaps, but also instantly broke the
slave server, which stopped returning results and instead logged lots of
slapd[27944]: => mdb_idl_fetch_key: cursor failed: Invalid argument (22)
lines. Having no better idea, I restarted the slave server, which
fortunately returned it to normal working condition.
So, my questions:
1. How does the "self-recognition" (by which the master does not start
replicating from itself) work, why did it fail when I changed the
provider URI to ldaps? Did using a CNAME (instead of some FQDN of
the server) confuse it? Could this be fixed by adding an appropriate
subjectAltName to the server TLS certificate? Or by adding some
olcServerID attributes?
2. How could I have handled the read-only situation, instead of editing
forbidden LDIF files? Would setting olcMirrorMode have been
possible (without olcServerIDs around)?
3. Is my setup in a reliable and consistent state now, or should I
expect sudden future failures? I mean, were the "cursor failed"
errors fixed for good by the slave server restart?
Please also feel free to educate me on any other points, as needed. :)
--
Thanks,
Feri.
8 years, 8 months
memberof in openldap
by Brad Hartlove
I have been trying to include the memberOf attribute in a new objectClass.
If I just set it to "MAY" (for example), it complains about using an
operational attribute in my definition. I have seen quite a few Q&As about
this, but I am really trying to understand where this issue is
originating. Maybe I haven't looked at the right one yet. OpenDJ has
the ability to utilize it in custom classes, so I was hoping to be able to
also do the same in OpenLDAP. Thoughts?
8 years, 8 months
OpenLDAP Installation and Extending Schema Walkthru
by Tim Watkins
I am somewhat knew to LDAP and have been trying to find a fully functioning
WalkThru to install OpenLDAP 2.4.39 on an Ubuntu 12.04 or 13.10. After
installing I would like to have the same for extending the Schema.
I have tried multiple times with ones that I have found online or YouTube,
but so far, everything is missing something or another.
If someone has document to point me that is complete, it would be greatly
appreciated!
Tim
8 years, 8 months
