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
4 years, 2 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)
4 years, 3 months
slapd-meta
by Fr3ddie
Hello to the list,
I'm trying to configure the slapd-meta OpenLDAP backend on an online
cn=config
configuration with no luck. Slapd version is 2.4.39 (the maximum I can
achieve on the target machines building from vanilla source).
The documentation is clear but too concise for me so I will try to explain
what I'm trying to do to see if there is anybody that can help me.
Currently I have 3 slapd servers that share a common root for the DIT, i.e.:
dc=loc1,dc=root
dc=loc2,dc=root
dc=loc3,dc=root
What I would like to achieve is to obtain a fourth server that contains
the previous trees, along with its own tree, i.e. a server that contains:
dc=loc0,dc=root (locally hosted data)
dc=loc1,dc=root (coming from the first server, chasing referrals)
dc=loc2,dc=root (coming from the second server, chasing referrals)
dc=loc3,dc=root (coming from the third server, chasing referrals)
this way, all the clients connecting to this server will be able to
retrieve data also from the other three remote servers.
As far as I understood, I only need to configure the "loc0" server to access
the other three servers and get the data to serve to clients.
I have already configured the fourth server with its local DIT and this is
the configuration:
# cat 'cn=config.ldif'
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
structuralObjectClass: olcGlobal
creatorsName: cn=config
olcServerID: 1
olcThreads: 32
olcToolThreads: 8
olcRequires: LDAPv3
olcConnMaxPendingAuth: 100
olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem
olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key
olcTLSVerifyClient: try
olcTimeLimit: 600
olcLogLevel: stats2 sync
[...]
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
structuralObjectClass: olcModuleList
[...]
Schema files are the following:
cn={0}core.ldif
cn={1}cosine.ldif
cn={2}nis.ldif
cn={3}inetorgperson.ldif
cn={4}dyngroup.ldif
cn={5}kerberos.ldif
# cat 'olcDatabase={1}hdb.ldif'
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=loc0,dc=root
olcAccess: {0}to
attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn
=admin,dc=loc0,dc=root" write by anonymous auth by self write by *
none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=loc0,dc=root
olcRootPW:: xxxxxxxxxxxxxxxxxxxx
olcDbCacheSize: 10000
olcDbCheckpoint: 512 10
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 30000
olcDbIndex: default pres,eq
[...]
structuralObjectClass: olcHdbConfig
olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root
bindmethod=s
imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx
searchbase="dc=loc0,dc=root"
logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj
ect)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="60 +" syn
cdata=accesslog starttls=yes
olcMirrorMode: TRUE
[...]
On top of this DB I have the "syncprov" and the "accesslog" overlays
configured
(these are two servers in "MirrorMode", configured following the
OpenLDAP admin documentation).
I believe this DB is the ones containing the actual "loc0" DIT data...
Then I have the accesslog DB for the replica (with the syncprov overlay
on top):
# cat 'olcDatabase={2}hdb.ldif'
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=loc0,dc=root
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
[...]
On top of this environment I start loading the needed modules with this
LDIF file:
version: 1
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap
-
add: olcModuleLoad
olcModuleLoad: back_meta
-
add: olcModuleLoad
olcModuleLoad: rwm
and it seems I'm able to load the new modules without errors
into the configuration, thus I obtain:
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
structuralObjectClass: olcModuleList
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
olcModuleLoad: {3}back_ldap
olcModuleLoad: {4}back_meta
olcModuleLoad: {5}rwm
[...]
Now I try to load the slapd-meta directives into a new database using
this LDIF:
version: 1
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=root
olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
but I obtain an error that sticks me trying various combinations without
success:
# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Object class violation (65)
additional info: attribute 'olcDbURI' not allowed
and:
# tail /var/log/openldap/slapd.log
Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM
oid=1.3.6.1.4.1.4203.1.9.1.4
Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:57:07 server01 slapd[32392]: Entry
(olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed
Into the slapd-meta documentation the "URI" directive is mentioned but
the "DbURI" seems to
raise a "better error", in fact if I try to modify the above LDIF file
using "URI" I obtain:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Undefined attribute type (17)
additional info: olcUri: attribute type undefined
Moreover, it is not stated into the slapd-meta docs that the slapd-ldap
backend is needed by slapd-meta but,
anyway, I think its needed because if I try to load the slapd-meta alone
it raises an error (I don't remember exactly which one).
At this point I'm stuck to this error and I wasn't able to find any hint
on the web to solve this :(
The examples I was able to find were related with the static slapd.conf
configuration, I counldn't
find any "full" configuration example using the cn=config.
I'm wondering if I should create a "cn=root" actual DB first and then
link the sub-DITs to it,
or, maybe, add some other overlay... I really can't understand how it
should work :(
Can please anybody help me?
Thank you very much
4 years, 11 months
OpenLDAP server attack surface analysis shows UDP port 63515 in unknown state
by Sreekanth Sukumaran
Sorry, I missed to add subject in the last mail. Resending with subject.
sorry about spamming the group
Hi All,
OpenLDAP version : 2.4.39 on windows
Tool used : Microsoft Attack surface analyzer
We have been doing attack surface analysis on OpenLDAP server, and we have
found that there is an UDP port 63515 associated with OpenLDAP server.
(state shows "Unknown", not listening or established)
[image: Inline image 1]
We have not connected any clients to OpenLDAP server, so we cannot think of
it as an ephemeral port at server end as well.
Has anyone an idea on what this port could be for. Inputs are much
appreciated.
--
Regards,
Sreekanth
--
Regards,
Sreekanth
09036794524
5 years
Re: LMDB: Ignore SIGPIPE in mdb_env_copythr
by Howard Chu
Lorenz Bauer wrote:
> Hello Hallvard, List,
>
> I'd like to propose explicitly ignoring SIGPIPE in the copy thread via
> pthread_sigmask, and returning EPIPE to the caller instead.
Feel free to submit a patch to the ITS, according to
http://www.openldap.org/devel/contributing.html
Since it seems this is a pretty small change, I suggest your IPR notice should
place your changes into the public domain.
>
> This is a change that makes little sense in the C world, since the
> caller can simply adjust the sigmask before calling the function
> (which is indeed what the utilities do). However, this amount of
> control is not always given, e.g. when using LMDB from Go (which is
> what I am doing).
>
> Due to the way the Go runtime works, using mdb_env_copyfd2 with
> CP_COMPACT on a pipe or a network connection will abort the whole
> process with SIGPIPE if the reading end of the fd is closed
> prematurely. The details why this happens are in [1]. Go has some
> additional trickery when dealing with stdin and stdout, so ignoring
> SIGPIPE for the whole process is undesirable (details in [2]).
>
> I understand that you might be reluctant to change the behaviour due
> to the constraints of a different runtime. However, I think that even
> in the C world it is surprising that calling a library function can
> abort your process.
>
> What are your thoughts regarding this? I think the code changes would
> be small, and the API would not change for consumers of the library.
>
> 1: https://golang.org/pkg/os/signal/#hdr-Go_programs_that_use_cgo_or_SWIG
> 2: https://golang.org/pkg/os/signal/#hdr-SIGPIPE
>
> Best,
> Lorenz
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years
RedHat 6 & 7 disable TLSv1.0
by Gaurav Swami
Hello,
I have Redhat 6 where am trying to disable TLSv1.0 protocol.I have tried
below configuration
RHEL6
-----------------------------------------
[root@ldap1 ~]# rpm -qa | grep -we openldap -we openssl -we nss
krb5-pkinit-openssl-1.10.3-10.el6_4.6.x86_64
openldap-servers-2.4.40-12.el6.x86_64
nss-util-3.21.0-2.el6.x86_64
nss-3.21.0-8.el6.x86_64
openssl-devel-1.0.1e-48.el6_8.1.x86_64
openssl-1.0.1e-48.el6_8.1.x86_64
openldap-clients-2.4.40-12.el6.x86_64
nss-softokn-freebl-3.14.3-23.3.el6_8.x86_64
nss-sysinit-3.21.0-8.el6.x86_64
nss-tools-3.21.0-8.el6.x86_64
openldap-2.4.40-12.el6.x86_64
nss-softokn-3.14.3-23.3.el6_8.x86_64
----------------------------------------------------------------------------
RHEL6 Configuration
----------------------------------------
TLSProtocolMin 3.2
TLSCipherSuite HIGH
-----------------------------------------
But still when I ran third party tool to check offered protocol am getting
--> Testing protocols (via sockets except TLS 1.2 and SPDY/NPN)
SSLv2 not offered (OK)
SSLv3 not offered (OK)
TLS 1 offered
TLS 1.1 offered
TLS 1.2 offered (OK)
SPDY/NPN not offered
--> Testing ~standard cipher lists
TLSv1.0 is still offered ,I want to disable TLSv1.0 also
Any suggestiosn?
--
Thanks & Regards,
**Gaurav Swami**
5 years
Fine grained access to attributes
by Ralf Mattes
Just a quick question: isit possible to control access to attributes based on an attribute tag?
The idea is to hide certain attributes by adding a "...;x-hidden' tag.
TIA Ralf Mattes
:wq
5 years
Syncrepl initial sync provider sends entries in wrong order
by Γ. Μηλιώτης
Hello everyone,
I'm wondering if a syncrepl behaviour I'm seeing is correct. My consumer
is 4.4.42 and my provider 4.4.40. I'm using refreshOnly replication and
when I first create the database entry on the consumer the whole process
stops after 5-6 records.
I have tested the syncuser and its searches against the provider return
>9000 results. So it's not a limit or auth issue. I have matched the
schemas on both servers successfully. I believe the issue is that the
provider is sending the records in an incorrect order.
I get a record with an entryCSN in 20151001 and then a record with an
entryCSN before that. So, if I understand it, operating correctly, the
consumer complains the record is too old and ignores it, stopping
replication. The contextCSN of the provider is in the 2016* range, the
consumer's is stuck in 2015* range and the log spams "too old". I'm
using the -c rid=XXX option to run slapd and deleting the DB between tests.
Shouldn't the provider send the entries in a entryCSN-ascending order
during the initial sync?
Thanks for any insight you can provide.
--GM
5 years
N-Way replication
by rammohan ganapavarapu
Hi,
I have n-way replication setup in ldap version 2.4.43 and i have basic
technical question, do we have to specify nth server details in replication
config? lets say i have server1 server2 and server3 and i wanted to setup
n-way replication among these servers
Part of my config looks like this
# Global section
serverID 1 ldap://server1
serverID 2 ldap://server2
serverID 3 ldap://server3
# database section
# syncrepl directive
syncrepl rid=001
provider=ldap://server1
syncrepl rid=002
provider=ldap://server2
syncrepl rid=003
provider=ldap://server3
mirrormode on
So if i include the nth server itlsef in the replication provider
doesn't it try to replicate it self and get it into loop condition?
Please advice
Thanks,
Ram
5 years
Re: Fwd: Using lmdb as a pure in memory store
by Howard Chu
Russell Haley wrote:
> Thanks so much for your response and thanks for the link. I've been
> pouring over that documentation off and on.
>
> The developer currently doing the prototyping has said he ran into an
> issue where the use of a very large key value caused the system to
> slow down (he didn't give specifics and I didn't have time to ask). He
> said it was a sparsely populated record set of about 100,00 rows but
> he specifically used a large value for the key as we hope to support
> UInt64 for keys (I don't know why, apparently we're indexing
> sub-atomic particles?). I saw a setting for MDB_MAXKEYSIZE which was
> 0 for computed, but I don't know what that means on an ARM (v6 - 32
> bit) system. Would you have any idea what would cause the performance
> hit he was referring too?
At a guess, you're slowing down because you're using 64bit values on a 32bit
processor and once you exceed the range of a 32bit integer you need twice as
many memory accesses to fetch/compare keys. Anyway, if you're using
MDB_INTEGERKEY (which you should be, in this case) then you'll never get
anywhere near the max keysize.
> Sorry if my questions are weird, I'm trying to learn C and embedded
> development through osmosis.
>
> Anyway, on a personal note, I was thoroughly happy to get lmdb working
> in Lua through
>
> https://github.com/shmul/lightningmdb
>
> and can't wait to try his Mule Round-Robin Database tool
>
> https://github.com/shmul/mule
>
> Awesome stuff.
>
> Russ
>
>
> On Thu, Sep 22, 2016 at 4:25 PM, Howard Chu <hyc(a)symas.com> wrote:
>> Russell Haley wrote:
>>>
>>> Hello,
>>>
>>> I wasn't fully subscribed when I sent this so I'll send it again.
>>>
>>> Any input or reference hints would be great. I love reading manuals. :)
>>
>>
>> http://lmdb.tech/doc/
>>>
>>>
>>> Russ
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Russell Haley <russ.haley(a)gmail.com>
>>> Date: Tue, Sep 20, 2016 at 4:52 PM
>>> Subject: Using lmdb as a pure in memory store
>>> To: openldap-technical(a)openldap.org
>>>
>>>
>>> Hi there,
>>>
>>> We are currently evaluating in memory key value stores for ~100,000 -
>>> 200,000 records in an embedded system. I suggested lmdb but it is
>>> being discounted for some reasons I thought I'd validate:
>>>
>>> 1) It is currently thought that a on disk file is REQUIRED for the
>>> system. Does MDB_NOSYNC turn off the disk caching? Can it be run as a
>>> pure in-memory database? Could the file not just be mapped to a
>>> memdisk?
>>
>>
>> A file is required. Whether the file is on-disk or not is irrelevant. It can
>> of course be on a RAMdisk (or, in Linux, a tmpfs), which would then make it
>> pure in-memory.
>>
>> MDB_NOSYNC turns off syncing, that's why it is named that.
>>
>>> 2) Because these values can come very fast, that the use of a lock
>>> file would cause delay and too much wear on the nand based disk (SSD).
>>
>>
>> No. That's not how the lock file is used.
>>
>>> I see a no locking option ( MDB_NOLOCK) that would stop a lock file
>>> being written.
>>
>>
>> This option should only be used if you're implementing your own lock
>> manager. Hint - no matter what approach you use, any other lock manager you
>> use will be slower than LMDB's.
>>
>>> Again, another option would be mapping the lock file to
>>> a memdisk to handle that?
>>
>>
>> Yes.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
5 years, 1 month
