How to enable memberOf overlay with posixGroup?
by MegaBrutal
Hi all,
I've spent days trying to figure out how could I enable the memberOf
overlay, and it doesn't seem to be easy for an LDAP-noob. I've read
like 50+ tutorials which didn't help me get it working.
Use case: I want to have 2 main groups which control access to
different services on my network. A "unixusers" which is a minimum to
log in to Linux servers (having a hostObject entry for the user is
another requirement, which is irrelevant to this question, as I
already solved that problem); and a "cloudusers" group which enables
log in to my ownCloud instance.
The groups should enforce the following rules:
– Only users in "cloudusers" should be allowed to log in to ownCloud.
– Users in "unixusers" are allowed to log in to a set of Linux servers
controlled by "host" (hostObject) entries.
– Users not in the "unixusers" group may not log in to any Linux
systems, even if they have "host" entries.
Problems:
– ownCloud complains that the memberOf overlay is not enabled, hence
it doesn't let me restrict access to the "cloudusers" group. It would
allow any users regardless of any group memberships, which is not
acceptable.
– I have a similar problem on Linux with PAM: I can't really get it to
consider "unixusers" membership for user logins, although I got the
"host" entries working correctly, so at least I can already restrict
access with that.
My guess is that it all boils down to the lack of memberOf overlay. I
also figured that memberOf would need groupOfNames groups, while I
need posixGroup type groups. I evaluated the possibility to use
groupOfNames, but it lacks the necessary gidNumber attribute which is
a requirement for Unix groups. But anyway, I can't enable memberOf
even for groupOfNames. I can't enable memberOf by any means.
My OpenLDAP uses the new configuration method and it completely
ignores slapd.conf, so the config must be injected with ldapadd to
cn=config.
Could you please help me with this?
Regards,
MegaBrutal
3 years, 3 months
[Q] "selective" ACL
by Zeus Panchenko
hi,
I'm trying to configure a not complex (as I believe) ACL ... but have some
difficulties
I have two posixGroup groups
cn=admins,ou=group,dc=foo
cn=coadmins,ou=group,dc=foo
my users resides in ou=People,dc=foo
so, in subtree ou=People,dc=foo I need to allow anything to admins (and
it is not difficult of course)
for example this works for me:
access to dn.subtree="ou=People,dc=foo"
by set="[cn=admin,ou=group,dc=foo]/memberUid & user/uid" manage
by self write
by users read
by * break
but in addition I need to allow my coadmins to do the same things except
manipulations upon the objects which belong to admins (
...anyobject,uid=adminuser,ou=People,dc=foo )
so, the question is: how? (if it is possible at all) :(
please, advise
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
3 years, 4 months
Change log timestamp: rsyslog changes don't work
by mdii
Hi all,
I'm trying to change the timestamp appears in my openLDAP logs. Today it's
the default timestamp (Nov 22 11:55:02), but for debugging reasons I need
to show the milliseconds (something like Nov 22 11:55:02:987 or any other
format with milliseconds).
The logs output are managed by the /etc/rsyslog.d/openldap.conf file:
> #Configuration specifique openldap
> local4.* @10.2.32.95:514
> local4.* -/custom/log/openldap.log
> local5.* @10.2.32.95:514
> local5.* -/custom/log/openldap-oldschema.log
My /etc/rsyslog.conf configuration looks like:
> # Use default timestamp format
> $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
For testing purposes, I change it to:
> # Use default timestamp format
> $ActionFileDefaultTemplate RSYSLOG_FileFormat
Or even to:
> # Use default timestamp format
> $template myFormat,"PRI: %pri%, MSG: %msg%\n"
> $ActionFileDefaultTemplate myFormat
But I see no changes in the timestamp (I restart the rsyslog service at
each modification)
I also notice that I'm just getting the first instance log
(-/custom/log/openldap.log), I'm not seeing the second one
(-/custom/log/openldap-oldschema.log).
Viewing this I have two questions:
- why my second instance doesn't log?
- why my log timestamp doesn't change when I change the configuration file?
I would like to thank you in advance for all the help,
Marc
4 years
Re: slapo-smbk5pwd build fixes
by Quanah Gibson-Mount
--On Saturday, November 05, 2016 7:30 PM -0700 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> --On Saturday, November 05, 2016 6:30 PM +0200 Emmanuel Dreyfus
> <manu(a)netbsd.org> wrote:
>
>> Hello
>>
>> slapo-smbk5pwd does not link with newer OpenSSL,because the old des_*
>> API was removed. This simple patch uses the new (but available for a
>> long time) DES_* API to fix that:
>> http://www.openldap.org/its/index.cgi/Incoming?id=8525;selectid=8525
>
> Hi Emmanuel,
>
> The openldap-devel list would be the appropriate place to raise and
> discuss this. I will try and look into it further on Monday.
This is now in RE24, scheduled for the 2.4.45 release.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years
replicate cn=config with exception of "ACLs"
by Stanislav Kopp
Hello,
at the moment we're using master<->slave setup with slapd 2.4.31 using
old slapd.conf. I want to migrate all to "cn=config" and if possible
replicate cn=config DB to slaves for sake maintenance simplicity, but
with exception ofr ACLs rules, because master and slaves have
different ACLs.
Is it possible, or ist it a good idea in general?
The plus of slapd.conf was that I can deploy the same ACL file on all
slaves with some automation (e.g. puppet).
Thanks,
Stan
4 years
Re: OID syntax and NAMEs
by Howard Chu
Michael Ströder wrote:
> Howard Chu wrote:
>> Michael Ströder wrote:
>>> Eventual I'd like to have a constraint like this:
>>>
>>> # check whether appropriate password policy is assigned
>>> constraint_attribute structuralObjectClass,pwdPolicySubentry
>>> set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
>>
>> Not possible without custom code.
>
> Hmm, are this/structuralObjectClass and this/pwdPolicySubentry generally
> unusable in set-constraints?
>
> Or does it not work because of the different matching rules?
Yes, because of the matching rule issue.
This seems to be a deficiency in either ASN.1 or the LDAP spec, I'm not sure
which. The problem is that numeric OIDs are obviously unique, but there's no
guarantee that string names are. Moreover, the same name might apply to the
OID of an attribute, or an objectclass, or a syntax, or some other entity, and
there's no way to tell the objectIdentifierMatch rule which context is
relevant. So, we can only match on numeric OIDs.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years
Re: OID syntax and NAMEs
by Howard Chu
Michael Ströder wrote:
> HI!
>
> I've declared an attribute type like this with LDAP syntax OID:
>
> ( 1.3.6.1.4.1.5427.1.389.100.4.18
> NAME 'aeApplicableSOC'
> DESC 'AE-DIR: structural object classes for which policy is applicable'
> EQUALITY objectIdentifierMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
> X-ORIGIN 'AE-DIR' )
>
> Which is pretty similar to this:
>
> ( 2.5.4.0
> NAME 'objectClass'
> DESC 'RFC4512: object classes of the entity'
> EQUALITY objectIdentifierMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
>
> Now I wonder why I can't use the object class NAMEs instead of the OIDs as
> attribute or assertion values, e.g. why I can't find the entries with filter
> (aeApplicableSOC=aeUser).
>
> This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in
> 'pwdPolicy' entries.
It's the exact same issue. The objectIdentifierMatch function only works with
numeric OIDs. The ppolicy overlay inserts its own matching function to make
the name work.
>
> Eventual I'd like to have a constraint like this:
>
> # check whether appropriate password policy is assigned
> constraint_attribute structuralObjectClass,pwdPolicySubentry
> set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
Not possible without custom code.
>
> Ciao, Michael.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4 years
Re: Ldap not reachable/tuning
by Quanah Gibson-Mount
--On Friday, November 25, 2016 7:05 PM +0100 Thomas Hummel
<thomas.hummel(a)pasteur.fr> wrote:
> Hello,
>
> I'm using a simple setup on CentOS Linux release 7.2.1511
> (Core)/openldap-servers-2.4.40-9 /cn=config/mdb : one provider with the
> syncprov overlay and 2 syncrepl consumers. The DIT itself is about 10000
> dn in size (about 3000 active users).
>
> Everything works fine except that sometimes, some clients report
> (temporary) failure to reach the consumers (NAS servers for instance).
Hi Thomas,
A few notes:
a) The CentOS7 build is hacked to support a broken TLS implementation.
b) The version (2.4.40) is quite old, and has numerous known problems (it
was a particularly broken release). I would also note the CentOS7 build
has on occassion had its own problems introduced by patches from RedHat
that do not exist in stock OpenLDAP builds. See
<http://www.openldap.org/software/release/changes.html> for a list of
changes since 2.4.40 was released.
c) Nothing you presented indicates any issue on the server side. It could,
for example, be an issue with your clients, a firewall, packet shaper, etc.
d) You should fully disable rate limiting for rsyslogd. Then find out what
the server side reports during the periods of time when you see issues with
the client connections.
You may wish to examine the LTB builds
(<http://ltb-project.org/wiki/download#openldap>) if you are unable to
build OpenLDAP yourself, or if you require support for your OpenLDAP
installation, Symas (the company I work for) has support options.
Hope this helps!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years
OID syntax and NAMEs
by Michael Ströder
HI!
I've declared an attribute type like this with LDAP syntax OID:
( 1.3.6.1.4.1.5427.1.389.100.4.18
NAME 'aeApplicableSOC'
DESC 'AE-DIR: structural object classes for which policy is applicable'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
X-ORIGIN 'AE-DIR' )
Which is pretty similar to this:
( 2.5.4.0
NAME 'objectClass'
DESC 'RFC4512: object classes of the entity'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Now I wonder why I can't use the object class NAMEs instead of the OIDs as
attribute or assertion values, e.g. why I can't find the entries with filter
(aeApplicableSOC=aeUser).
This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in
'pwdPolicy' entries.
Eventual I'd like to have a constraint like this:
# check whether appropriate password policy is assigned
constraint_attribute structuralObjectClass,pwdPolicySubentry
set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
Ciao, Michael.
4 years
"attr" Warning in slapcat
by Kilian
Hi,
having a strange warning:
# /usr/sbin/slapcat -b dc=foo,dc=bar,com
583422d0 /etc/ldap/slapd.d: line 1: "attr" is deprecated (and
undocumented); use "attrs" instead.
Then, the normal output of slapcat follows.
The thing is, /etc/ldap/slapd.d is a *folder* and in the entire
/etc/ldap folder, including subdirs, the string "attr" does not occur.
Btw, The contents of /etc/ldap/slapd.d are:
-rw------- 1 openldap openldap 2386 Jun 5 13:51 cn=config.ldif
drwxr-x--- 6 openldap openldap 4096 Nov 20 20:32 cn=config
Can anyone give me a hint, what is going on?
Best, Kilian
4 years
