openldap-technical March 2020

openldap-technical@openldap.org

22 participants
28 discussions

Re: back-ldap SASL proxy authorization
by Dieter Bocklandt 06 Mar '20

06 Mar '20

Hey Quanah, Thanks for getting back to me! So as I understood it, I expected the proxied identity to be the identity that the client successfully authorized as instead of the identity it initially started with. The session tracking request is just there to confirm that piece of information is actually present but not used. That initial identity is also used for ACL evaluation on the producer side, leading to insufficient access (as expected). To give a maybe more clear example, assume the following users (stripped down to just the relevant attributes in play): *dn: cn=proxy,ou=System,dc=example,dc=netauthzTo: dn:** *dn: cn=service,ou=System,dc=example,dc=net * *authzTo: dn:uid=user,ou=People,dc=example,dc=net * *dn: uid=dieter,ou=People,dc=example,dc=net * *and the following idassert config:* *olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX * When I perform an operation like this: ldapmodify -H ldaps://ldapserver -Y PLAIN -U service -X dn:uid=dieter,ou=People,dc=example,dc=net -w servicepassword -f modifications.ldif I would assume the following takes place: - The service user binds to the consumer and assumes dieter's identity, which should be the same net effect as binding with dieter's user in the first place. - The proxy user binds to the provider and assumes dieter's identity - The provider tries to perform the write, using dieter's identity for ACL evaluation What actually happens: - The service user binds to the consumer and assumes dieter's identity - The proxy user binds to the provider and assumes the service user's identity - The provider tries to perform the write, using the service user's identity for ACL evaluation Actually, I spent some more time on this today and I *think* I might know what's happening here: (from servers/slapd/back-ldap/bind.c in master): line 2222 - 2227: *if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; }* line 2549 - 2557: *if ( op->o_tag == LDAP_REQ_BIND ) { ndn = op->o_req_ndn; } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) { ndn = op->o_conn->c_ndn; } else { ndn = op->o_ndn; }* It seems it tries to use op->o_conn->c_ndn if it's not null, which is (correct me if I'm wrong) the original authcID. That value however doesn't change when performing a proxy authorization, while op->o_ndn does properly reflect that. Shouldn't OpenLDAP always use op->o_ndn? Again, let me know if I can provide more information or tell me if I'm grossly misunderstanding how this is all supposed to work in the first place :) Thanks! // Dieter On Wed, 4 Mar 2020 at 23:12, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Friday, February 28, 2020 11:11 PM +0100 Dieter Bocklandt > <dieterbocklandt(a)gmail.com> wrote: > > > However, we also have a service using SASL proxy authorization, in which > > case the authcid is used in the ProxyAuthz instead of the authorized > > authzid. > > > > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ > > dn="cn=service,ou=system,dc=internal,dc=machines" > > Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 > > [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD > > dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" > > > > Am I misunderstanding how this is supposed to work, am I hitting a > > certain limitation or maybe a bug? Let me know if you need any more > > details! > > This looks to me like it: > > a) Logs what the proxied identity is (PROXYAUTHZ > dn="cn=service,ou=system,dc=internal,dc=machine") > > b) Logs what the actual identity making the changes is > (USERNAME=cn=enduser,ou=People,dc=example,dc=net) and what IP address it > came from (IP=10.243.72.199) so that if questions arise about who made a > change, those questions can be answered from the logs. > > I.e., I see both bits of information provided in the connection operation. > > What makes you think you are hitting a limitation or a bug? > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

4 3

Re: openldap-technical Digest, Vol 148, Issue 6
by Dieter Bocklandt 06 Mar '20

06 Mar '20

Hey Michael, I would assume that for the proxy it shouldn't matter how the client got authenticated to the consumer. Mode=self should just try and assert the resulting authzID to the target. The identity of the proxy is only there so we have something to bind with to the producer. With mode=none, that identity would also be used for the actual ACL evaluation, but that would just lead to all writes being done by seemingly 1 user, making auditing impossible ... Cheers, //Dieter On Fri, 6 Mar 2020 at 13:00, <openldap-technical-request(a)openldap.org> wrote: > > ---------- Forwarded message ---------- > From: "Michael Ströder" <michael(a)stroeder.com> > To: openldap-technical(a)openldap.org > Cc: > Bcc: > Date: Thu, 5 Mar 2020 21:46:12 +0100 > Subject: Re: back-ldap SASL proxy authorization > On 3/5/20 9:04 PM, Howard Chu wrote: > > Dieter Bocklandt wrote: > >> I would assume the following takes place: > >> - The service user binds to the consumer and assumes dieter's identity, > which should be the same net effect as binding with dieter's user in the > first place. > >> - The proxy user binds to the provider and assumes dieter's identity > >> - The provider tries to perform the write, using dieter's identity for > ACL evaluation > >> > >> What actually happens: > >> - The service user binds to the consumer and assumes dieter's identity > >> - The proxy user binds to the provider and assumes the service user's > identity > >> - The provider tries to perform the write, using the service user's > identity for ACL evaluation > >> > >> Actually, I spent some more time on this today and I /think/ I might > know what's happening here: > > > > Your analysis makes sense. Would have to ask Pierangelo why he wrote it > the way he > > did but it seems that it should use op->o_ndn. > > Hmm, is the semantics of proxying the SASL proxy authorization clearly > defined? The consumer proxy itself also has an identity. > > Just asking... > > Ciao, Michael. > > > _______________________________________________ > openldap-technical mailing list > openldap-technical(a)openldap.org > http://www.openldap.org/lists/mm/listinfo/openldap-technical >

1 0

Antw: [EXT] Re: pwdChangedTime not defined when creating new entry
by Ulrich Windl 05 Mar '20

05 Mar '20

>>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am 05.03.2020 um 10:10 in Nachricht <25580_1583399661_5E60C2EC_25580_1796_1_20200305101027.4c15a1d1(a)pink.fritz.box>: > Am Wed, 04 Mar 2020 13:36:08 +0000 > schrieb Manuela Mandache <manuela.mandache(a)protonmail.com>: > >> Hello all, >> >> We have a directory running on OpenLDAP 2.4.44 with the ppolicy >> overlay on the main database. When a new entry with a userPassword >> defined is created, pwdChangedTime is not defined, so this initial >> userPassword never expires. >> >> The directory has been migrated from its OpenLDAP 2.3.34 instance >> (yes, we missed some steps...), and there the pwdChangedTime is set, >> and naturally equal to createTimestamp. >> >> The overlay is configured as follows: >> dn: olcOverlay={2}ppolicy,olcDatabase={2}mdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcPPolicyConfig >> olcOverlay: {2}ppolicy >> olcPPolicyDefault: ou=ppolicy,dc=example,dc=com >> olcPPolicyHashCleartext: TRUE >> olcPPolicyUseLockout: TRUE >> >> Is there a parameter I missed which would switch on setting >> pwdChangedTime at entry creation? Do I have to provide some other >> configuration elements? >> >> Or is it unreasonable to expect this initialisation of the attribute >> this way, and only a password change can set it? I think the setting >> at creation is rather handy... Using pwdMustChange would be >> difficult, we have a lot of client apps which would be forced to >> check and probably adapt their authentication procedures. > [...] > The password attribute value must be set by a password modify exented > operation in order to set password policy in effect, see man > slapo-ppolicy(5) Yes, but shouldn't there be some magic to add it to all existing passweords when enabling it? Without having each user to change the password... > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E

2 1

back-ldap SASL proxy authorization
by Dieter Bocklandt 04 Mar '20

04 Mar '20

Hi! We have a fairly standard OpenLDAP setup (on 2.4.49) running well, where our replica instances chain writes back to the master using the chain overlay. Relevant bits of configuration we're using below: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: mode=self flags=override,prescriptive tls_reqcert=never bindmethod=sasl saslmech=plain authcID=proxy credentials=XXXXX olcDbRebindAsUser: TRUE olcDbChaseReferrals: TRUE olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 8 olcDbSessionTrackingRequest: TRUE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbIdleTimeout: 5 . . . dn: cn=proxy,ou=System,dc=example,dc=net cn: proxy objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: XXXXX authzTo: {0}dn.regex:^uid=[^,],ou=People,dc=example,dc=net$ Above works great, with the client identity being authorized through the ProxyAuthz control. However, we also have a service using SASL proxy authorization, in which case the authcid is used in the ProxyAuthz instead of the authorized authzid. Ldapwhoami works as expected and the username mentioned in the session tracking request (visible in the producer's logs) is actually the authzdn (being cn=enduser,ou=People,dc=example,dc=net in this example, whereas cn=service,ou=system,dc=internal,dc=machines is the authcdn): ldapwhoami -H ldaps://$(cat /etc/service_hostname) -U service -X dn:cn=enduser,ou=People,dc=example,dc=net -Y PLAIN SASL/PLAIN authentication started Please enter your password: SASL username: dn:cn=enduser,ou=People,dc=example,dc=net SASL SSF: 0 dn:cn=enduser,ou=People,dc=example,dc=net Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 PROXYAUTHZ dn="cn=service,ou=system,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD dn="uid=sys.cp.test,ou=People,dc=internal,dc=machines" Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] MOD attr=klarnaItNote Feb 28 22:02:38 ldap-master-az2 slapd[1915]: conn=26858 op=2 [IP=10.243.72.199 USERNAME=cn=enduser,ou=People,dc=example,dc=net] RESULT tag=103 err=0 text= Am I misunderstanding how this is supposed to work, am I hitting a certain limitation or maybe a bug? Let me know if you need any more details! Thanks! Dieter Bocklandt

2 1

identifying anonymouns binds
by Geert Hendrickx 04 Mar '20

04 Mar '20

Hi I'd like to inventorise (and eventually disable) anynomous binds on an LDAP server with many different client applications. I am evaluating stats logs, and I see that most anonymous binds are logged as: conn=32743 op=0 BIND dn="" method=128 conn=32743 op=0 RESULT tag=97 err=0 text= However some connections log no BIND operation at all, just SRCH ops etc. I cannot replicate this behaviour with ldapsearch, it comes from an old java client. So looking for 'BIND dn=""' is not enough - how can I reliably identify anonymous binds? Looking for each op=0 and if it's not a SRCH, assume it's an anonymous bind as well? We have no "features" like bind_v2, bind_anon_cred etc enabled. Second question is what is the proper way to disable anonymous access? Through access controls (which we already have in place for fine-grained write access control), or on server-wide level by 'disallow bind_anon' ? Thanks Geert -- geert.hendrickx.be :: geert(a)hendrickx.be :: PGP: 0xC4BB9E9F This e-mail was composed using 100% recycled spam messages!

2 1

ldap_sasl_interactive_bind_s: Local error (-2) for SASL/GSS-SPNEGO
by Debashis Chaki 02 Mar '20

02 Mar '20

Hi , I have installed openldap but I am getting the following error while executing some basic command using SASL/GSS-SPNEGO authentication Where as SASL/EXTERNAL authentication working perfectly. [root@dtgldap103 LdapCfg]# ldapsearch SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapwhoami SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapsearch -LLL -s base -b '' '(objectClass=*)' + SASL/GSS-SPNEGO authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (SPNEGO cannot find mechanisms to negotiate) [root@dtgldap103 LdapCfg]# ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcDatabase=config SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: olcDatabase=config # requesting: ALL # # {0}config, config dn: olcDatabase={0}config,cn=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 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@dtgldap103 openldap]# rpm -qa | grep ldap sssd-ldap-1.15.2-50.el7_4.2.x86_64 openldap-clients-2.4.44-5.el7.x86_64 openldap-servers-sql-2.4.44-5.el7.x86_64 openldap-servers-2.4.44-5.el7.x86_64 compat-openldap-2.3.43-5.el7.x86_64 openldap-devel-2.4.44-5.el7.x86_64 openldap-2.4.44-5.el7.x86_64 nss-pam-ldapd-0.8.13-8.0.1.el7.x86_64 Please help me how can I get out of this issue ? I am not able to proceed further for our openldap project without that. Please let me know if you need any more details. Thanks & Regards <http://www.proquest.com/> Debashis Chaki ProQuest | The Quorum, Barnwell Road | Cambridge | CB5 8SW | UK debashis.chaki(a)proquest.com tel: +44 (0)1223 271257 Better research. Better learning. Better insights.

2 3

Re: With MDB Openldap seems to be pretty slower in Windows
by Vijay Kumar 01 Mar '20

01 Mar '20

Thank Quanah, for the response. Can i request to let me know what is WSLv2 you meant for? -Vijay Kumar On Fri, Feb 28, 2020 at 10:52 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Friday, February 28, 2020 8:58 AM -0800 Quanah Gibson-Mount > <quanah(a)symas.com> wrote: > > >> We have a 110 users data by performance testing, where we observed > >> slowness for windows 10 OS. > > > > This is not a topic for -devel, please post to -technical instead. > > Ugh, even worse, you double posted. DO NOT DOUBLE POST. > > I would suggest testing WSLv2. ;) > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > -- Thanks & Regards, Vijay Kumar *+91-94944 44009*

2 1

SASL domain no longer recognised
by Rick van Rein 01 Mar '20

01 Mar '20

Hello, I have a demo setup with slapd on Debian Stable, and a while back followed Debian's Switch to Buster, with slapd 2.4.47. Since about that time, slapd stopped recognising its SASL realm. This is in a dev/demo/test environment in Docker, so naming is a bit silly, but that always worked. Config and such are shown at https://github.com/arpa2/docker-demo/tree/master/demo-reservoir Using "ldapsearch -Y GSSAPI -H ldap://reservoir.arpa2:1388 -b ou=Reservoir,o=arpa2.net,ou=InternetWide" gives the message SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No key table entry found matching ldap/reservoir.arpa2@) **In this output, note the lacking realm after the @.** This appears to be a server-side issue, because the client had the realm in the klist output and that name is present in the keytab: 02/29/20 11:54:53 02/29/20 21:47:26 ldap/reservoir.arpa2(a)ARPA2.NET renew until 03/01/20 11:47:22 The configuration of the server in /etc/ldap/slapd.conf still says: sasl-host reservoir.arpa2 sasl-realm ARPA2.NET FWIW, slapd runs as /usr/sbin/slapd -d any -h "ldapi://%2ftmp%2fldap-socket ldap://:1388/" Have I missed changes to slapd? Are there log messages that I overlooked (or should selected for)? Thanks! -Rick

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2020