Antw: [EXT] Re: pwdChangedTime not defined when creating new entry
by Ulrich Windl
>>> 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
3 years, 7 months
back-ldap SASL proxy authorization
by Dieter Bocklandt
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
3 years, 7 months
identifying anonymouns binds
by Geert Hendrickx
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!
3 years, 7 months
ldap_sasl_interactive_bind_s: Local error (-2) for SASL/GSS-SPNEGO
by Debashis Chaki
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.
3 years, 7 months
Re: With MDB Openldap seems to be pretty slower in Windows
by Vijay Kumar
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*
3 years, 7 months
SASL domain no longer recognised
by Rick van Rein
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
3 years, 7 months
