openldap-technical August 2019

openldap-technical@openldap.org

33 participants
47 discussions

Problem with "force user to password reset at first login
by Rajagopal Rc 30 Oct '23

30 Oct '23

Hi, I am trying to force users to change their password at first login or after password reset by administrator. Tried following: 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non of the users get prompt to change their password at first login. 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't prompt to change the password and didn't allow to login i observe below messages in log "slapd[12684]: connection restricted to password changing only slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are restricted to bind/unbind/abandon/StartTLS/modify password" slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password" Please help me configure the option to force all users to change their password at first login or after pwd reset by administrator. Thanks & Regards Raj Tata Consultancy Services Mailto: rajagopal.rc(a)tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you

5 9

Q: UNKNOWN attributeDescription "AUDITCONTEXT" inserted.
by Ulrich Windl 23 Jul '20

23 Jul '20

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

4 10

Dynamic ACL in OpenLDAP with set:expand not working
by Martin W. 27 Aug '19

27 Aug '19

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

3 4

Procedure going from search query to an acl
by Marc Roos 27 Aug '19

27 Aug '19

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)

2 1

Q: Multiple accesslog overlays?
by Ulrich Windl 27 Aug '19

27 Aug '19

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

3 10

Adding syncprov to running slapd
by Marc Roos 27 Aug '19

27 Aug '19

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?

3 2

Socat tcp to local socket
by Marc Roos 27 Aug '19

27 Aug '19

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.

1 2

RE: Socat tcp to local socket
by Marc Roos 26 Aug '19

26 Aug '19

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

1 0

Complex setup to do back-ldap AND SASL auth in one go
by Markus.Storm＠t-systems.com 26 Aug '19

26 Aug '19

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

2 2

Re: Socat tcp to local socket
by Giuseppe De Marco 25 Aug '19

25 Aug '19

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. > > > > > > >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical August 2019