slapd ACL to allow Password Modify exop by ldappasswd - but deny direct modification via ldapmodify
by Tim Watts
Hi,
I've been through google and the man pages - no avail. If anyone can
help, I'd be very grateful :)
slapd.conf acl:
access to attrs=userPassword
by peername.path="/var/run/slapd/ldapi" manage
by dn="cn=admin,dc=dighum,dc=kcl,dc=ac,dc=uk" manage
by self write
by * auth
This allows ldappasswd to work, but of course, it also allows anybody to
issue an ldapmodify against their own record and store a weak hash (eg
{crypt} ) or worse, bypass my check_password plugin policy enforcer.
Removing the "self write" line kills ldapmodify, but also seems to break
the password modify exop issues by ldappasswd.
So - how do I allow ldappasswd to work (which respects the policies and
allows the server to hash the password using its default hash - SSHA1 in
my case) whilst disallowing *direct* modify access to the userPassword:
entry?
Answers on a postcard, or a wet herring as appropriate :-|
Many thanks!
Tim
--
Tim Watts
Personal Blog: http://squiddy.blog.dionic.net/
http://www.sensorly.com/ Crowd mapping of 2G/3G/4G mobile signal coverage
8 years, 1 month
ppolicy pwdCheckModule failure and still calling other overlays
by Tim Watts
I realise this is a long shot,
but if pwdCheckModule is enabled in ppolicy AND the module it calls
FAILS a prospective password (for being too weak) - should slapd
actually be calling the next overlay in the stack?? Common sense says
ppolicy should bomb out?
Here are the overlay configs in slapd.conf:
<backend hdb database stuff>
overlay smbkrb5pwd
smbkrb5pwd-enable krb5
smbkrb5pwd-krb5realm DIGHUM.KCL.AC.UK
smbkrb5pwd-requiredclass posixAccount
#
# Password Policy - this runs check_password.so compiled from
# /vol/source/ldap_check_password/1.0/check_password.c
#
#
overlay ppolicy
ppolicy_default "cn=default,ou=pwpolicies,dc=dighum,dc=kcl,dc=ac,dc=uk"
ppolicy_use_lockout
ppolicy_hash_cleartext
The idea is:
ppolicy is configured to call my own password_check.so and that works
nicely - that exits with EXIT_FAILURE if it fails.
smbkrb5pwd is OpinSys.fi's modification to smbk5pwd to work with MIT
kerberos. That works too (after I fixed something). It will set the
principle's password and create the principle is it doesn't exist.
The failure scenario is:
1) No principle for the UID in question;
2) The UID in question has a DN in slapd;
3) Set password for UID - choose one that will fail the ppolicy checks;
4) do an ldappasswd change for UID
Result: ldappasswd says it fails and the user password hash in slapd is
not changed. However, smbkrb5pwd was still called and managed to create
a principle for UID with the weak password - bypassing the policy.
The best answer to my mind is:
Fix smbkrb5pwd to be able to add a default kerberos policy to any
created principles. Such a policy can replace ppolicy for password
strength checking. I think I can do this.
However, it bothers me - is there no way to make the failure of one
overlay bomb the stack out (rather like PAM)?
Or perhaps ppolicy is not actually "failing" as such??
Any ideas?
Cheers!
Tim
--
Tim Watts
Personal Blog: http://squiddy.blog.dionic.net/
http://www.sensorly.com/ Crowd mapping of 2G/3G/4G mobile signal coverage
8 years, 1 month
Indices is missing?
by Vit Dua
Hi,
I have indexed my mdb by:
slapcat -f slapd.conf -q
After that, I can find entries quickly with the filter:
mail=viet...(a)example.com
But I cannot find the entry:
mail=viet2000000(a)example.com,dc=example,dc=com
with that filter.
However, I can search that entry with other filter:
mail=viet200000*(a)example.com
My slapd.conf:
index mail eq
Thanks,
Viet
8 years, 1 month
openLDAP is not working with MySQL cluster
by SHEKHAR PODICHETI
Hi,
I tried connecting openLDAP server with MySQL cluster through NDB APIs. I
made configuration changes in slapd.conf so that it connect to NDB.
However it is throwing Unrecongnized NDB.
I request tou to help me. It will be great if u share me sample slapd.conf
file that has the NDB configuration.
Thanks.
--
Regards,
Shekhar Podicheti
8 years, 1 month
ppolicy on consumers
by Andrei BĂNARU
Hi,
Did anyone manage to get the *ppolicy overlay* to work on the *consumers *?
The user gets the *pwdAccountLockedTime *attribute on the provider and
the consumers. To validate this I use:
/[root@opennms ~]# //*ldapwhoami -x -e ppolicy -D
"uid=user1,ou=People,ou=Country1,dc=example,dc=com" -w'password' -h
ldap-master.example.com*//*
*//*ldap_bind: Invalid credentials (49); Account locked*/
where *ldap-master.example.com* is the *provider*.
/[root@opennms ~]# //*ldapwhoami -x -e ppolicy -D
"uid=user1,ou=People,ou=Country1,dc=example,dc=com" -w'password' -h
ldap.example.ro*//*
*//*dn:uid=user1,ou=People,ou=Country1,dc=example,dc=com*/
where *ldap.example.ro* is one of the *consumers*.
The same issue occurs also on expired passwords.
On the consumer I've used *ppolicy_forward_updates* and that works like
a charm.
Did I miss something vital in the configuration ?
Thx!
--
Andrei BĂNARU
Internal Support
CCNA Security, CCIP
StreamWIDE Romania
8 years, 1 month
meta backend subtree directive ignored by conversion to cn=config
by francesco.policastro＠selex-es.com
Hi all,
I realized that the subtree-include directives I use in my meta backend
are not converted at all to cn=config.
I cannot find them in cn=config tree.
The slapd version is 2.4.33 as patched after ITS#7525
(openldap-648d28f.tar.gz)
Here is my slapd.conf:
====================================================
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/dyngroup.schema
attributetype ( 1.2.840.113556.1.4.221 NAME 'sAMAccountName'
EQUALITY caseExactMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.35 NAME 'employeeID'
EQUALITY caseExactMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.8 NAME 'userAccountControl'
EQUALITY integerMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.27' SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.656 NAME 'userPrincipalName'
EQUALITY caseExactMatch
SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE )
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
pidfile /var/run/slapd.pid
# ----------------------
backend meta
backend hdb
# ----------------------
# ----------------------
database meta
# ----------------------
suffix "dc=newco,dc=com"
readonly on
rootdn "cn=LdapBindUser,dc=newco,dc=com"
rootpw secret1
# no anonymous bind
require authc
conn-ttl 25m
dncache-ttl disabled
access to *
by * none
# first domain
uri "ldap://server1.it.domain1.com/dc=first,dc=newco,dc=com"
idassert-bind bindmethod=simple binddn="cn=LDAP
User,ou=ITStaff,dc=it,dc=domain1,dc=com" credentials=secret2
chase-referrals no
rebind-as-user true
map objectclass groupOfNames *
map objectclass person *
suffixmassage "dc=first,dc=newco,dc=com" "dc=it,dc=domain1,dc=com"
subtree-include "ou=Applications,ou=Groups
Shared,dc=first,dc=newco,dc=com"
subtree-include "ou=Users,ou=1st-location,dc=first,dc=newco,dc=com"
subtree-include "ou=Users,ou=2nd-location,dc=first,dc=newco,dc=com"
subtree-include "ou=Users,ou=3rd-location,dc=first,dc=newco,dc=com"
# map visible attributes to matching attributes on backend
map attribute distinguishedName *
map attribute givenName *
map attribute description *
map attribute sn *
map attribute cn *
map attribute mail *
map attribute samAccountName *
map attribute userAccountControl *
map attribute employeeID *
map attribute userPrincipalName *
# map everything else to null
map attribute *
# second domain
uri
"ldap://server2.domain2.net/ou=organizationalUnit,dc=second,dc=newco,dc=com"
idassert-bind bindmethod=simple
binddn="cn=ldap-2,cn=Users,dc=domain2,dc=net" credentials=secret3
chase-referrals no
rebind-as-user true
map objectclass groupOfNames *
map objectclass person *
suffixmassage "dc=second,dc=newco,dc=com" "dc=domain2,dc=net"
subtree-include
"ou=Users,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com"
subtree-include
"ou=My-ou,ou=1st-location,ou=organizationalUnit,dc=second,dc=newco,dc=com"
subtree-include "ou=Remote
Sites,ou=organizationalUnit,dc=second,dc=newco,dc=com"
# map visible attributes to matching attributes on backend
map attribute distinguishedName *
map attribute givenName *
map attribute description *
map attribute sn *
map attribute cn *
map attribute mail *
map attribute samAccountName *
map attribute userAccountControl *
map attribute employeeID pager
map attribute userPrincipalName *
# map everything else to null
map attribute *
# ----------------------
database hdb
# ----------------------
suffix dc=domain-groups,dc=com"
rootdn "cn=groupsRoot,dc=domain-groups,dc=com"
rootpw secret4
overlay dynlist
dynlist-attrset groupOfURLs memberURL member
directory /usr/local/var/openldap-data
=============================================
Did anyone successfully use subtrees with cn=config?
Thanks,
Francesco Policastro
8 years, 1 month
Openldap Chaining
by jeevan kc
Hello guys here is my proceudre that I wrote for OpenLDAP chaining. My question is since I have a master and two slaves on the replication, where do these overlay go? On the slaves only or both master and slaves. Please respond. Thanks
·
Create
/usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend
·
Create
/usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend/olcOverlay={0}chain
·
Add olcOverlay={0}chain.ldif to /usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend
dn: olcOverlay={0}chain
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE
structuralObjectClass:
olcChainConfig
·
Add olcDatabase={0}ldap.ldif to
/usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend/olcOverlay={0}chain
dn: olcDatabase={0}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: none
starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
structuralObjectClass:
olcLDAPConfig
·
Add olcDatabase={1}ldap.ldif to
/usr/local/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend/olcOverlay={0}chain
dn: olcDatabase={1}ldap
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://master.dc.us"
olcDbStartTLS: none
starttls=no
olcDbIDAssertBind: mode=self
flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0
network-timeout=0 binddn="cn=manager,o=dc,c=us”
credentials="l4s3rj3t"
keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
structuralObjectClass: olcLDAPConfig
·
Restart
slapd
8 years, 1 month
Listing linux users
by Thiago Parolin
Hi all.
My scenario is:
openldap/samba pdc server for authenticating Windows and Linux.
I need to know when a user, from Linux clients, logs in and out from the
system.
If some problem occurs, i need to know who was logged, in particular
computer, in that time.
With windows computers, the "last" bash command (in server) gave me the
information needed, but with linux clients i don't know what i have to do.
They are not listed with "last" command.
I don't want to redirect all auth logs from clients to my server. It
probably will overload my server.
There are some way to do this?
8 years, 2 months
