Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl
Hi!
After systemd tearing down one of our LDAP servers I noticed the following message when the server was restarted:
slapd[10525]: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
The next line logged was:
slapd[10525]: olcServerID: value #1: SID=0x002 (listener=ldap://...:389)
(the server is that of SLES12 SP4, 2.4.41 from opensuse-buildservice)
The server is one of three MM servers that all have the same configuration and the same version.
The schema knows in olcAttributeTypes (olcSchemaConfig):
( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )
What I'l like to know: Is there any thing I could fix in the configuration to make the message go away, or is it some software issue in slapd?
Regards,
Ulrich
3 years, 2 months
Dynamic ACL in OpenLDAP with set:expand not working
by Martin W.
Dear OpenLDAP technical list,
I‘ve been running into a little problem with my permission structures – and was wondering if you could help me with it.
I want the members of a group to administer a tree structure, the group is member of it. I've tried some acl settings – I'll post my trials below the basic structure.
Basic structure
The structure is somehow like that tree – behind an # symbol, there is a brief description what the entries are meant for.
> dc=example,dc=com
> │
> ├── cn=admin # OpenLDAP default admin user
> │
> ├── ou=entities # organisational entities
> │ │
> │ ├── o=e1 # first of these entities
> │ │ │
> │ │ ├── cn=admin # groupOfNames – see bullet points below
> │ │ │ ┆
> │ │ │ └ ┄▸ member: cn=admin,dc=example,dc=com
> │ │ │ └ ┄▸ member: uid=j.doe,ou=people,dc=example,dc=com
> │ │ │
> │ │ ├── cn=role1 # groupOfNames to be reused below
> │ │ │ ┆ as recursive group members within
> │ │ │ ┆ permission groups
> │ │ │ ┆
> │ │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com
> │ │ │
> │ │ └── cn=role2
> │ │ ┆
> │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com
> │ │
> │ └── o=e2
> │ ├── cn=admin
> │ ├── cn=role1
> │ └── cn=role2
> │
> ├── ou=groups # permission groups for applications
> │ │ that authenticate against OpenLDAP
> │ │
> │ ├── cn=globaladmins # groupOfNames – superusers in all applications
> │ │ ┆
> │ │ └ ┄▸ member: cn=admin,dc=example,dc=com
> │ │
> │ ├── cn=ldapadmins # groupOfNames – same rights as admin user
> │ │ ┆
> │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com
> │ │ └ ┄▸ member: uid=l.dap,ou=people,dc=example,dc=com
> │ │
> │ ├── cn=permissiongroup1 # groupOfNames – authentication group
> │ │ ┆ for specific application
> │ │ ┆
> │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com
> │ │ └ ┄▸ member: cn=role1,o=e1,ou=entities,dc=example,dc=com
> │ │ └ ┄▸ member: cn=role1,o=e2,ou=entities,dc=example,dc=com
> │ │
> │ └── cn=permissiongroup2
> │ ┆
> │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com
> │ └ ┄▸ member: cn=role2,o=e1,ou=entities,dc=example,dc=com
> │ └ ┄▸ member: cn=role2,o=e2,ou=entities,dc=example,dc=com
> │
> └── ou=people # finally the "real people" accounts
> │
> ├── uid=j.doe
> ├── uid=l.dap
> └── uid=m.muster
cn=admin,dc=example,dc=com is basic member of the admin groups (since every group needs at least one member).
uid=l.dap,ou=people,dc=example,dc=com is member of the cn=ldapadmins,ou=groups,dc=example,dc=com group. Therefor every member should have same rights within LDAP structure as cn=admin,dc=example,dc=com
ou=people is the only structure, (personal) accounts are maintained
ou=groups is the only structure, authentication groups for (web)applications are maintained (with nested members)
The cn=admin,o=e1,ou=entities,dc=example,dc=com DN members should be able to admin everything below o=e1,ou=entities,dc=example,dc=com.
e1 should be dynamic.
The entity admins should not be able to administer other entities than the ones, they are admins from.
Permission LDIF
I've tried some different things ... and none Regex was successful :(
Since I'll post some fragments, I put every LDIF fragment within such a bash fragment:
> touch /permissions.ldif
>
> cat >/permissions.ldif <<EOF
> # first of all delete all permissions
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> delete: olcAccess
> -
>
> ########
> ## LDIF blocks from below
> ########
>
> -
> # add general permissions
> add: olcAccess
> olcAccess: to *
> by self write
> by dn="cn=admin,dc=example,dc=com" write
> by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write
> by users read
> by * none
> EOF
>
> ldapmodify -Q -Y EXTERNAL -H ldapi:/// <ldapi:///> -f /permissions.ldif
trial 1
> # add administrative access to LVe admin subgroups
> add: olcAccess
> olcAccess: to dn.regex="([^,]+,)?o=([^,]+),ou=entities,dc=example,dc=com"
> by self write
> by dn="cn=admin,dc=example,dc=com" write
> by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write
> by set.expand="[cn=admin,o=$2,ou=entities,dc=example,dc=com]/member* & user" write
> by set="this/member* & user" read
> by * none
The result is, that admin and any member of ldapadminscan edit, the members of specific entity admin subgroups cannot edit.
The specific admin subgroups cannot even see the entities subtree.
trial 2
> # add administrative access to LVe admin subgroups
> add: olcAccess
> olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com"
> by self write
> by dn="cn=admin,dc=example,dc=com" write
> by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write
> by set.expand="[cn=admin,o=$1,ou=entities,dc=example,dc=com]/member* & user" write
> by set="this/member* & user" read
> by * none
The same result as with trial 1 ...
trial 3
Additional groups – as a tree:
> dc=example,dc=com
> ┆
> └── ou=entity_admins
> │
> ├── cn=e1
> │ ┆
> │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com
> │
> └── cn=e2
And the LDIF:
> # add administrative access to LVe admin subgroups
> add: olcAccess
> olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com"
> by self write
> by dn="cn=admin,dc=example,dc=com" write
> by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write
> by set.expand="[cn=$1,ou=entity_admins,dc=example,dc=com]/member* & user" write
> by set="this/member* & user" read
> by * none
The result is again: admin and any member of ldapadminscan edit, entity_admins subgroups user cannot edit – even not their "owned" entities.
trial 4
If I put an by set="[cn=admin,o=e1,ou=entities,dc=example,dc=com]/member* & user" write for EVERY single olcAccess: to dn.regex="([^,]+,)?o=jpbay,ou=entities,dc=example,dc=com" (with all the other stuff from trial 1), everything works fine.
BUT: that's not maintainable or dynamic. So that's no solution, I can accept.
I do not know why set.expand doesn't work as expected (as explained within different online examples on openldap.com <http://openldap.com/>) – and was not able to find a proper documentation that could explain why. Or if there has to be some enablement of an OpenLDAP module?
If you could support me with that problem – probably with a solution – it would be great =)
Thanks a lot,
Martin
4 years, 1 month
Procedure going from search query to an acl
by Marc Roos
I have client that coredumps with these acl's. When I remove them, the
client is getting data from the ldap server and I can see the queries it
is doing on the server. I thougt the lines below would give access to
ou=Services and below by test, but I guess not.
dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0} to dn.exact="" by * read
olcAccess: {1} to dn.exact="cn=Subschema" by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self
read by ssf=256 anonymous auth by * none
olcAccess: {3} to dn.exact="ou=Services,dc=example,dc=local"
attrs="children" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local"
ssf=64 read by * break
olcAccess: {4} to dn.children="ou=Services,dc=example,dc=local" by
dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read
olcAccess: {5} to * by * none
acl_mask: access to entry "name=asdf,ou=Services,dc=example,dc=local",
attr "bla" requested
acl_mask: access to entry "ou=Services,dc=example,dc=local", attr
"entry" requested
I guess I should grep the log for the acl_mask entries not? What would
be an adviced procedure to do this? I also do not want to get a huge
list of acls for just one client type. Everything below
"ou=Services,dc=example,dc=local" is test to read. (No password
attributes stored there)
4 years, 1 month
Q: Multiple accesslog overlays?
by Ulrich Windl
Hi!
I have a question preparing a transition of syncrepl to delta-syncrepl:
Our database already has an accesslog overlay (olcAccessLogOps: writes) and a corresponding database configured for monitoring purposes.
Now that delta syncreply also requires an accesslog overlay/database with somewhat different setting compared to the existing database, I wonder whether it's possible (and practically being used/proven to work) to have multiple accesslog overlays.
Thinking about it, I also wonder whether both needs for accesslog could be satisfied with one accesslog database, just using different LDAP filters. I guess the delta syncreply is using the acesslog database in a read-only manner (our monitoring also does), so it might actually work. Anybody went that way before?
Finally a question on the requirement to backup the acesslog database in addition to the corresponding database (18.2.1: "Note: since the database state is stored in both the changelog DB and the main DB on the provider, it is
important to backup/restore both the changelog DB and the main DB using slapcat/slapadd when restoring a
DB or copying it to another machine."): Is it actually a hard requirement needed for consistency, or will it just improve the performance (avoiding a full refresh)?
Also: Isn't it tricky to backup both databases consistently while the database is writable?
Regards,
Ulrich
4 years, 1 month
Adding syncprov to running slapd
by Marc Roos
I am adding the syncprovider to a running server with these:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
However when I do slapd -VVV the overlay is not listed. Do I need to
1. restart?
2. use syncprov.la instead of syncprov?
4 years, 1 month
Socat tcp to local socket
by Marc Roos
Anyone having some experience using socat (or something similar?) to
connect to a remote slapd server tcp/tls with a local socket? I have a
client that requires the local ldapi socket. But I do not want to
install there an instance of slapd.
4 years, 1 month
RE: Socat tcp to local socket
by Marc Roos
Hi Harry,
I just did a build from srpm, and currently I trying to get the scenario
of a pipe between sockets working. Just to make sure this pipe is
working correctly before I am moving to the tcp/tls connection.
Of course my problem persists with socat using something like this.
socat -s -d -d -d -t 3 UNIX-CONNECT:/var/run/ldapi,raw,ignoreeof
UNIX-LISTEN:/var/run/bla,raw,ignoreeof,fork
You have a suggestion how to to do this with dpipe, I have tried this
dpipe vde_plug /var/run/ldapi = vde_plug /var/run/bla
But it does not launch nor reports the error.
-----Original Message-----
Subject: Re: Socat tcp to local socket
>
> With this I am able to issue just one ldap search on the socket.
> Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact
> LDAP server (-1)'
Sure, use either very long timeouts or use an other tool, i.e. dpipe.
The problem with socat is, socat terminates after each ldapsearch.
dpipe only stops, if manual terminated. Their are some other useful
tools in vde2 package.
>
> socat -d -d
> OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify=
> 0,
> keepalive,reuseaddr,ignoreeof
> UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof
>
> I am just wondering if this is even possible, maybe the tcp
> connections keeps an authorized session? Or ldapi communication is
just different?
> If this ldapi communication is different from ldaps. I guess I am only
> left with the options like
> - connecting with some forwarded ssh session to the local ldapi server
> socket
> - maybe export ldapi with stunnel on the server, and capture it again
> with stunnel/socat
> - look into slapd proxy/meta
>
>
>
>
>
>
>
>
>
--
Harry Jede
4 years, 1 month
Complex setup to do back-ldap AND SASL auth in one go
by Markus.Storm＠t-systems.com
Dear all,
I am desperately trying to setup an OpenLDAP instance "P" with a proxy or other backend or even chain of proxies to do the following and I just don't manage to wrap my head around it. I'd be thankful if someone could give me a helping hand and provide me with the missing link. Apologies upfront for the lengthy mail and complicated setup, but for organizational reasons, I have a couple of constraints that I cannot change.
Scenario:
Ultimately I want some UNIX machines using pam-ldap to authenticate against an Active Directory ("AD").
Logins to those machines require a number of attributes but I don't have authority/ability to store them in the AD. They are stored in an external (non-OpenLDAP !) server "S" instead.
As the AD passwords cannot be read/replicated, I also cannot simply direct clients to S, so I want to direct them to an OpenLDAP instance "P" to "split" the request, i.e. do authentication against AD using external auth/SASL (that part already works) while retrieving the attributes from S.
I have this working to some extent but needed to create a copy of the user data on S in my openLDAP server/proxy P.
But I'm trying to avoid the need to have those copies in P, I want it to be dataless to avoid all need for synchronization (as S is non-OpenLDAP I cannot simply replicate).
I'm open to suggestions but I think it would need to work like this:
1. Client "C" connects to P with say binddn cn=user,dc=domain and password pw
2. P proxies all requests for dc=domain to S using a generic binddn (instead of the user credentials) to have access to the subtree the users are in
As of today I wouldn't know how to configure that binddn on P.
1. S has an entry for every user with userpassword={SASL}user@domain and a couple of attributes which all are returned to P
S is the only place where we can store those attributes (and the instruction to use SASL - or is there another place for that ?)
But authentication of C against S fails when I use the user's credentials (because of the "{SASL}..." contents on S).
Obviously S is unable to interpret/execute SASL auth format (if it was able that would be an obvious solution to my problem).
I also believe I cannot have ANOTHER userPassword attribute on S to have the user's password pw (S wouldn't know which of those 2 userPassword attributes to authenticate against).
1. P does SASL auth as user@domain and initially provided password against an Active Directory ("AD")
The SASL part already works but only if I setup another DB in P to contain a copy of the user data tree on S and userPassword="{SASL}user@domain" for all users.
Thanks in advance to anyone willing to wrap his head around my problem.
Best regards
Markus
4 years, 1 month
Re: Socat tcp to local socket
by Giuseppe De Marco
Hi Marc,
Slapd-proxy or slapd-meta could be the solution
Il dom 25 ago 2019, 14:42 Marc Roos <M.Roos(a)f1-outsourcing.eu> ha scritto:
>
> Anyone having some experience using socat (or something similar?) to
> connect to a remote slapd server tcp/tls with a local socket? I have a
> client that requires the local ldapi socket. But I do not want to
> install there an instance of slapd.
>
>
>
>
>
>
>
4 years, 1 month
openldap replication
by sami's strat
I'm trying to configure replication between two hosts using the following
as a guideline:
https://www.server-world.info/en/note?os=CentOS_7&p=openldap&f=5
Here are some notes I have based on the setup I've done:
##### REPLICATION ON Master #####
[root@ldap01 ~]# more mod_syncprov.ldif
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: syncprov.la
[root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f mod_syncprov.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"
[root@ldap01 ~]# more syncprov.ldif
dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpSessionLog: 100
[root@ldap01 ~]#
[root@ldap01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config"
[root@ldap01 ~]#
##### REPLICATION ON Slave #####
[root@ldap02 ~]# more syncrepl.ldif
dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001
provider=ldap://172.19.33.42:389/
bindmethod=simple
binddn="cn=admin,dc=ZZZ,dc=ZZZ"
credentials=password
searchbase="dc=ZZZ,dc=ZZZ"
scope=sub
schemachecking=on
type=refreshAndPersist
retry="30 5 300 3"
interval=00:00:05:00
[root@ldap02 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncrepl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={2}hdb,cn=config"
[root@ldap02 ~]#
# Testing LDAP
ldapsearch -x -b 'uid=testaccount,ou=People,dc=ZZZ,dc=ZZZ'
Both LDAP hosts work in the sense that I can authenticate to them. But
replication is not working.
Please help.
TIA
4 years, 1 month
