Re: Migrate from hdb/bdb to mdb backend.
by Quanah Gibson-Mount
--On Thursday, March 22, 2018 3:12 PM -0700 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
> olcSyncrepl: {0}rid=1 provider=ldap://ldapservertest01:10389/
> binddn="cn=manager,dc=example,dc=com" bindmethod=simple
> credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+"
> type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5
> network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub
> schemachecking=off
> olcSyncrepl: {1}rid=2 provider=ldap://ldapservertest02:10389/
> binddn="cn=manager,dc=example,dc=com" bindmethod=simple
> credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+"
> type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5
> network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub
> schemachecking=off
> olcSyncrepl: {2}rid=3 provider=ldap://ldapservertest03:10389/
> binddn="cn=manager,dc=example,dc=com" bindmethod=simple
> credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+"
> type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5
> network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub
> schemachecking=off
> olcSyncrepl: {3}rid=4 provider=ldap://ldapservertest04:10389/
> binddn="cn=manager,dc=example,dc=com" bindmethod=simple
> credentials=dontshare searchbase="dc=example,dc=com" attrs="*,+"
> type=refreshAndPersist retry="5 +" timeout=0 keepalive=5:5:5
> network-timeout=0 starttls=no filter="(objectclass=*)" scope=sub
> schemachecking=off
Remove the pointer back to itself on each server, so they stop trying to
replicate from themselves, or use a URL with the serverID.
Also, what version of OpenLDAP are you using?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 8 months
Re: Migrate from hdb/bdb to mdb backend.
by Quanah Gibson-Mount
--On Thursday, March 22, 2018 2:25 PM -0700 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
> serverID 300 ldap://ldapserver300
> serverID 301 ldap://ldapserver301
>From the slapd.conf man page for serverID:
"The fully qualified hostname of each server should be used in the
supplied URLs."
> And each of them have the same olcSyncrepl
You fail to note the olcServerID setting for the MDB cluster.
You fail to note the syncprov settings for any of the databases.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 8 months
Re: Migrate from hdb/bdb to mdb backend.
by Quanah Gibson-Mount
--On Wednesday, March 21, 2018 11:48 AM -0700 rammohan ganapavarapu
<rammohanganap(a)gmail.com> wrote:
> It seems data is getting replicate but i am seeing this message in ldap
> logs.
>
>
> 5ab27b63 dn_callback : entries have identical CSN (lot of them), i did
> find some post regarding this but couldn't find any conclusion. It seems
> like this message is because of node is trying to self replicate? can i
> have same node information in "olcSyncrepl" config when i am only
> replicating user database not config databse?
You've not provided any information on your configurations, so one cannot
really surmise anything about the validity of said configurations.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
5 years, 8 months
OpenLDAP: ACLs using sockname and DN?
by Norman Gray
Greetings.
In OpenLDAP (2.4.45, on FreeBSD), I'm trying to constrain the access of
a DN to an attribute, by giving a DN access only when the connection is
made via a socket; but without success. I may just be looking for an
example of correct use.
What I'm trying is
olcAccess: to attrs=userPassword
by dn.base="uid=pwreset,ou=service,dc=example,dc=edu"
sockname.exact="/var/run/openldap/ldapi"
write
(the idea is that the pwreset DN can be used by an automatic
password-reset script, but that that DN will have that access only when
the script is running on the same machine as the LDAP server).
This `by` phrase appears to match the production in Sect. 8.3 of the
OpenLDAP access control documentation, and the remark in slapd.access(5)
that the items in the <who> field ‘may be specified in combination’.
And indeed there are no syntax warnings generated. I'm presuming that
the combination implies an AND rather than an OR – this isn't made
explicit in the documentation. I can find no examples covering this in
either OpenLDAP documentation or on the web.
This stanza works when the sockname element is absent, suggesting that
the configuration is otherwise working as I expect.
When I try to write the userPassword attribute using this DN, I get an
ldap_modify: Insufficient access (50) error.
The OpenLDAP documentation doesn't (somewhat surprisingly) explicitly
state what the effect of this sockname element is, and the
slapd.access(5) page says, rather obliquely, that:
> The statements peername=<peername>, sockname=<sockname>,
> domain=<domain>, and sockurl=<sockurl> mean that the contacting host
> IP (in the form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for
> IPv6) or the contacting host named pipe file name (in the form
> PATH=<path> if connecting through a named pipe) for peername, the
> named pipe file name for sockname, the contacting host name for
> domain, and the contacting URL for sockurl are compared against
> pattern to determine access.
Saying 'determine access' doesn't actually say very much.
Have I completely misunderstood the point of this access specification,
or is there another way to do this?
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
5 years, 8 months
slapd ACL defintion for access to specific object class
by Space One
Hello,
I have a problem configuring correct ACL's:
If you want to grant access to a specific attribute and allow adding the
necessary object class for it, we could define:
Assuming objectClass is "O" and Attribute name is "A":
access to attrs=@O by self write by * +0 break
This works but it allows also access to any value in the "objectClass"
attribute and is therefor a massive security hole.
An alternative would be, which the manpage seem to describe
(https://linux.die.net/man/5/slapd.access):
access to attrs=objectClass value="O" by self write by * +0 break
access to attrs=A by self write by * +0 break
But when I apply this, and want to add the object class, I simply get
the INSUFFICIENT_ACCESS error code.
Maybe one can help?
If it's not possible I think the manpage should be adjusted and mention
this more explicit. Maye there is a exception for "objectClass"? Or it's
a bug in the implementation?
Best regards
spaceone
5 years, 8 months
Re: LMDB on Ramdisk (tmpfs)
by Luca Foppiano
> On 22 Mar 2018, at 11:31, Леонид Юрьев <leo(a)yuriev.ru> wrote:
>
> Hi.
Hi Leonid,
> Pages from tmpfs will be in "clean" state if ones swapped-out from RAM.
> But while stay in RAM such pages always "dirty”.
Thanks for the clarification.
Luca
5 years, 8 months
Re: learning olcAccess
by Lists Nethead
Quoting Sven Mäder <maeder(a)phys.ethz.ch>:
Thank you very much for this!
In our case we need access to dn.subtree I believe because admins are
supposed to have full control, ie. add and delete accounts.
What stopped me was the lack of documentation for the "control"
keyword but after a bit of sleep and reading your answer I found a
some deep down in the Faq-O-Matic bit it does not seem to cover all of
it.
So, as I gather, "by * none" is the default processing stops,
"by * continue" makes it possible to add rules to the same object and
"by * break" resets the processong?
And finally, there seems to be additional switches available for the
control processing but I cannot find them documented *anywhere*.
Thanks again,
//per
> Hi
>
> You could insert something like this:
>
> to dn.exact="ou=somedomain,dc=example,dc=com"
> attrs=children
> by group="cn=admingroup,ou=ldap,dc=example,dc=com" write stop
> by * break
> to dn.children="ou=somedomain,dc=example,dc=com"
> attrs=@inetOrgPerson,@organizationalUnit,@posixAccount,
> @shadowAccount,entry
> by group="cn=admingroup,ou=ldap,dc=example,dc=com" write stop
> by * break
>
> This will grant administrative rights by the specified group to:
>
> - the "children" attr of the entry: ou=somedomain,dc=example,dc=com
> - all attrs of children of: ou=somedomain,dc=example,dc=com in the
> specified objectClasses plus the entries itself
> - all other users/groups will continue with ACL evaluation (by * break)
>
> This will prevent modifying the entry: ou=somedomain,dc=example,dc=com
> If you do not need that, replace the two ACLs with:
>
> to dn.subtree=ou=somedomain,dc=example,dc=com"
> ...
>
> But you have to add these ACLs before the rule with:
> to attrs=userPassword ...
> otherwise if you add it at the end, the "by * none" will prevent all
> access.
>
> ou=ldap is just an ou that contains my slapd admin groups, for example:
>
> dn: ou=ldap,dc=example,dc=com
> objectClass: organizationalUnit
> ou: ldap
>
> dn: cn=admingroup,ou=ldap,dc=example,dc=com
> objectClass: groupOfNames
> member: uid=someuser,ou=somedomain,dc=example,dc=com
> cn: admingroup
>
> Hope that helps a bit with the bleeding :)
> And carefully test your ACLs, I had to do a lot of try and error to
> get it right.
>
> Kind regards
> Sven
>
> On 03/18/2018 04:54 PM, Lists Nethead wrote:
>>
>> Hi all,
>>
>> First post here, and it is asking for advice on an access rule. Setup is,
>>
>> +-dc=example,dc=com
>> +--ou=somedomain
>> +---uid=someuser,ou=somedomain,dc=example,dc=com
>> +--ou=someotherdomain
>> +---uid=otheruser,ou=someotherdomain,dc=example,dc=com
>> +--ou=yetanotherdomain
>>
>> The ruleset so far that seems to work is
>>
>> to dn.base="" by * read
>> to dn.base="cn=subschema" by * read
>> to attrs=userPassword by dn.base="cn=admin,dc=example,dc=com"
>> write by
>> dn.base="uid=otheradmin,ou=System,dc=example,dc=com" write by self
>> write by anonymous auth by * none
>> to * by dn.base="uid=someadmin,ou=System,dc=example,dc=com" w
>> rite by self read by
>> peername.ip=<address>%255.255.255.0 read by peern
>> ame.ip=<address>%255.255.255.0 read by peername.ip=<address>%255.255.2
>> 55.0 read by users tls_ssf=256 read by * none
>>
>> What I want next is that
>> "uid=someuser,ou=somedomain,dc=example,dc=com" should be able to
>> administer accounts in "ou=somedomain" and likewise for other "ou=".
>>
>> My guess is that a group with admin accounts is the way to go but
>> right now my eyes are bleeding after reading the whole day about
>> access rules...
>>
>> Thanks,
>>
>> //per
>>
>>
5 years, 8 months
I can't get relay to work in exposing a database under another suffix
by watery
Hello,
I'm trying to set up a replica of a remote server (suffix: ou=customer,o=main) in a local subtree (suffix: dc=example,dc=com).
The two separate databases work, as I can add entries to both of them using their original suffix with ldapmodify.
But no configuration of relay let's me query the replicated content using the local suffix, since ldapsearch either ends with "No Such Object" or doesn't terminate at all, it hangs after:
||connect success # extended LDIF # |ￜ... # LDAPv3 ||||# base <ou=users,dc=example,dc=com> with scope baseObject ||||# filter: (objectclass=*) ||||# requesting: ALL ||||# |Graphically it should look like this:
Remote server:
ou=customer,o=main
|
`-- ou=users,ou=customer,o=main
ￜￜￜ |
ￜￜￜ `-- ou=1000002052,ou=users,ou=customer,o=main
ￜￜￜ |
ￜￜￜ `-- ou=1000001458,ou=users,ou=customer,o=main
ￜￜￜ |
ￜￜￜ `-- ou=1000002113,ou=users,ou=customer,o=main
Local server:
dc=example,dc=com
|
`-- ou=customers,dc=example,dc=com
|ￜￜ |
|ￜￜ `-- cn=name-one,dc=example,dc=com
|ￜￜ |
|ￜￜ `-- cn=name-two,dc=example,dc=com
|
`-- ou=users,dc=example,dc=com
ￜￜￜ |
ￜￜￜ *
ￜￜￜ * (this is the replicated subtree, exposed under the new suffix)
ￜￜￜ *
ￜￜￜ |
ￜￜￜ `-- ou=1000002052,ou=users,dc=example,dc=com
ￜￜￜ |
ￜￜￜ `-- ou=1000001458,ou=users,dc=example,dc=com
ￜￜￜ |
ￜￜￜ `-- ou=1000002113,ou=users,dc=example,dc=com
Here's one of my attempts:
# Remote
database bdb
directory ...
suffix ou=customer,o=main
rootdn ...
rootpw ...
access to * by * manage
index ...
overlay memberof
# Relay
database relay
suffix ou=customers,dc=example,dc=com
relay ou=customer,o=main
overlay rwm
rwm-suffixmassage ou=customers,dc=example,dc=com ou=customer,o=main
# Local
database bdb
directory ...
suffix dc=example,dc=com
rootdn ...
rootpw ...
access to * by * manage
index ...
overlay memberof
overlay refint
refint_attributes member
refint_nothing "cn=nobody,dc=example,dc=com"
5 years, 8 months
Mirror mode not working with other user accounts
by Mark Monaghan
Hi All,
I'm looking for a bit of advice on my LDAP setup to see where I'm going wrong with this. I have searched high and low all over the internet for an answer, and I can't see to find anyone having the exact same issue. If anyone could shed any light on this, it would be great.
I've built two LDAP servers on Centos 7.4/OpenLDAP 2.4.44 running in mirror mode, and they are working successfully. I can create, delete, and edit entries on either server using the manager account, and the changes will be instantly mirrored over to the other server.
However, my problems started when I wanted to introduce two users to have full control over an OU each within the structure. I have put the ACLs for these users in place, and they work, but as soon as I do anything, even just an edit on an existing item in that OU, the change isn't mirrored over to the other server, and the server being mirrored to no longer replicates as it says the database is not a shadow.
The users in question are corpadmin and eduadmin, managing the Corporate and Education OUs respectively.
The ACLs in my databaseconfig file for the two users being place are as follows:
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=wireless,dc=org
structuralObjectClass: olcHdbConfig
creatorsName: cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=wireless,dc=org" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to dn.subtree="ou=Corporate,dc=wireless,dc=org" by dn="uid=corpadmin,ou=Admins,dc=wireless,dc=org" write by * read
olcAccess: {3}to dn.subtree="ou=Education,dc=wireless,dc=org" by dn="uid=eduadmin,ou=Admins,dc=wireless,dc=org" write by * read
olcAccess: {4}to * by dn="cn=Manager,dc=wireless,dc=org" write by * read
olcRootDN: cn=manager,dc=wireless,dc=org
The original databaseconfig file, minus the ACLs is like so:
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=wireless,dc=org
structuralObjectClass: olcHdbConfig
creatorsName: cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=wireless,dc=org" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=Manager,dc=wireless,dc=org" write by * read
olcRootDN: cn=manager,dc=wireless,dc=org
These ACLs have been added to the same file on the other server, so both ACLs match.
Is there anywhere else I should be making these ACL changes, such as the olcDatabase={0}config file (Pasted here for ref)?
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
olcRootPW:: 213jh287ycshasdkujqy7w483i1234jh123er7qwedfasdf
olcMirrorMode: TRUE
structuralObjectClass: olcDatabaseConfig
entryUUID: 507c5e6e-b24a-1037-9c97-89a2062470b8
creatorsName: cn=config
createTimestamp: 20180302094624Z
olcSyncrepl: {0}rid=001 provider=ldap://ldapauth1.fqdn.org binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
olcSyncrepl: {1}rid=002 provider=ldap://ldapauth2.fqdn.org binddn="cn=config" bindmethod=simple credentials=password searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
entryCSN: 20180302133047.428537Z#000000#002#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20180302133047Z
Finally, barring a restore of both servers, is there any way of bringing the two servers back into sync if I get a database is not a shadow error? Again, I've had a good look for information, but most posts mentioned that it was a bug with an earlier version of OpenLDAP and to upgrade to resolve this, rather than any info on how to resync the databases.
Thanks in advance.
Cheers,
Mark
5 years, 8 months
learning olcAccess
by Lists Nethead
Hi all,
First post here, and it is asking for advice on an access rule. Setup is,
+-dc=example,dc=com
+--ou=somedomain
+---uid=someuser,ou=somedomain,dc=example,dc=com
+--ou=someotherdomain
+---uid=otheruser,ou=someotherdomain,dc=example,dc=com
+--ou=yetanotherdomain
The ruleset so far that seems to work is
to dn.base="" by * read
to dn.base="cn=subschema" by * read
to attrs=userPassword by dn.base="cn=admin,dc=example,dc=com"
write by dn.base="uid=otheradmin,ou=System,dc=example,dc=com" write by self
write by anonymous auth by * none
to * by dn.base="uid=someadmin,ou=System,dc=example,dc=com" w
rite by self read by peername.ip=<address>%255.255.255.0 read by peern
ame.ip=<address>%255.255.255.0 read by peername.ip=<address>%255.255.2
55.0 read by users tls_ssf=256 read by * none
What I want next is that
"uid=someuser,ou=somedomain,dc=example,dc=com" should be able to
administer accounts in "ou=somedomain" and likewise for other "ou=".
My guess is that a group with admin accounts is the way to go but
right now my eyes are bleeding after reading the whole day about
access rules...
Thanks,
//per
5 years, 8 months
