Re: OpenSSL 1.1 Support ?
by Quanah Gibson-Mount
--On Wednesday, November 09, 2016 2:24 PM -0800 Norm Green
<norm.green(a)gemtalksystems.com> wrote:
> I've asked before and got nothing but crickets so I'm asking again.
>
> Any idea in what timeframe we will have a release of OpenLDAP that
> supports OpenSSL 1.1? 2016? 2017? 2018? Anyone? Bueller? Bueller? Is
> this thing even on?
Feel free to backport the commits for ITS#8353 and report back on how they
work for you.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
OpenSSL 1.1 Support ?
by Norm Green
I've asked before and got nothing but crickets so I'm asking again.
Any idea in what timeframe we will have a release of OpenLDAP that
supports OpenSSL 1.1? 2016? 2017? 2018? Anyone? Bueller? Bueller? Is
this thing even on?
Norm Green
4 years, 5 months
Re: Pverlay development documentation
by Howard Chu
Geoff Swan wrote:
> I have a need to write an overlay (openldap-2.4.44) and wondered if
> there was any documentation for overlay development?
servers/slapd/slapover.txt
> I have examined the sources in contrib/slapd-modules/ and was hoping to
> locate something a bit more descriptive and maybe any must-do's and
> gotchas for development.
>
>>From a development environment perspective, is it advisable to use the
> contrib/slapd-modules/ as a build location, using a Makefile based on
> one of the existing overlays and also the non-exposed header files (eg
> "portable.h") or not?
Makes no difference. Do whatever's convenient for you.
--
-- 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, 5 months
Pverlay development documentation
by Geoff Swan
I have a need to write an overlay (openldap-2.4.44) and wondered if
there was any documentation for overlay development?
I have examined the sources in contrib/slapd-modules/ and was hoping to
locate something a bit more descriptive and maybe any must-do's and
gotchas for development.
>From a development environment perspective, is it advisable to use the
contrib/slapd-modules/ as a build location, using a Makefile based on
one of the existing overlays and also the non-exposed header files (eg
"portable.h") or not?
- Geoff
4 years, 5 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, 5 months
Re: slapo-smbk5pwd build fixes
by Quanah Gibson-Mount
--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.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
Re: password sync issues
by Arun Gupta
Hi,
Thanks Anirudh.. for response, as I am newbie in openldap, please let me
know any already avaliabe script or some tutorial for the same.
Regards,
Arun
and I think
it may be also possible if On Thu, 3 Nov 2016, Anirudh Malhotra wrote:
> Hi,
>
> You can write a custom script which whenever the password is set in samba it
> sets it for the other tree as well, And you can attach this to the password
> changing app also.
>
> BR,
> Anirudh Malhotra
> Mail: 8zero2.in(a)gmail.com
> Facebook: www.facebook.com/8zero2
> Twitter: @8zero2_in
> Blog: blog.8zero2.in
>
> On Tue, Nov 1, 2016 at 6:49 PM, Arun Gupta <arung(a)cdac.in> wrote:
> Hi,
>
> I have configured 2 ldap tree, one for unix account (ou=User)
> (below is sample ldif)
>
>
> dn: uid=2011150,ou=User,dc=acer,dc=in
> empID: 2011150
> username: test1
> cn: test1
> centre: PN
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: top
> objectClass: shadowAccount
> oldempid: 1150
> mail: test1(a)acer.in
> givenName: test1
> uid: 2011150
> shadowLastChange: 15590
> loginShell: /bin/bash
> uidNumber: 11150
> gidNumber: 11150
> homeDirectory: /mbox4.2/test1
> userPassword: {SHA}1SrgdEGUPa/U6KM43Kq9xTgnI7A=
>
>
> and another for samba tree (ou=samba) - (below is sample tree)
>
> dn: uid=test1,ou=samba,dc=acer,dc=in
> uid: test1
> sambaSID: S-1-5-21-4079184197-2446238136-3299756537-1005
> displayName: test1
> sambaAcctFlags: [UX ]
> objectClass: sambaSamAccount
> objectClass: account
> sambaLMPassword: C2F63206FC9CF08A1AA818381E4E281B
> sambaNTPassword: 0242A7FEC5CD294F916925766089E573
>
> and I am able to authenticate with samba configuration. But I am
> not able to find out how the password will sync means if user
> change his password then how NT password will reflect (here two
> different tree). Is it possible to sync, if yes please please
> help me out.
>
> --
>
> Thanks & Regards,
>
> Arun Kumar Gupta
>
> ---------------------------------------------------------------------------
> ----------------------------------------------------
> [ C-DAC is on Social-Media too. Kindly follow us at:
> Facebook: https://www.facebook.com/CDACINDIA & Twitter:
> @cdacindia ]
>
> This e-mail is for the sole use of the intended recipient(s) and
> may
> contain confidential and privileged information. If you are not
> the
> intended recipient, please contact the sender by reply e-mail
> and destroy
> all copies and the original message. Any unauthorized review,
> use,
> disclosure, dissemination, forwarding, printing or copying of
> this email
> is strictly prohibited and appropriate legal action will be
> taken.
> ---------------------------------------------------------------------------
> ----------------------------------------------------
>
>
>
>
>
--
Thanks & Regards,
Arun Kumar Gupta
Mail Administrator
HPC Infrastructure and Ecosystem Group
Centre for Development of Advanced Computing
Savitribai Phule Pune University Campus
PUNE-Maharastra
Phone : +91-20-25704347
WEB : http://www.cdac.in/
-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]
This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------
4 years, 5 months
Re: delta-synrepl consumer randomly delete objects
by Quanah Gibson-Mount
--On Wednesday, October 26, 2016 10:07 AM +0200 Raffael Sahli
<public(a)raffaelsahli.com> wrote:
>> This is not delta-syncrepl, this is syncrepl. What triggered your
>> system to fall back to syncrepl?
> Tell me, I really don't know.
I can't tell you, it would be in your logs.
> Is this as designed? Syncrepl as fall back mechanism if delta-syncrepl
> failed? (But I don't know why delta-synrepl failed,
> how can I verify that delta-syncrepl does work properly)
Correct, if there is an issue, things will fall back to syncrepl. Again,
you'd have to look at your logs to determine why it fell back.
> However this should not happen with syncrepl anyways. How can it be that
> I have only 23 objects left on my consumer after
> a full re sync with thousands of objects?
Because syncrepl can be buggy?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
Re: Provider-Consumer replication 2.4 OLC (second attempt)
by Quanah Gibson-Mount
--On Friday, October 28, 2016 9:50 AM -0400 Ted Hyde <laserted(a)gmail.com>
wrote:
> Quanah - thanks for the response. Sorry to insult if I did - but thank
> you, I DID read the admin guide. Which as you have also pointed out uses
> slapd.conf examples. Since I am not knee-deep in commercial OpenLdap
> configuration every day (I am just a lowly IT admin, not a
> paid-to-openldap-person) I would disagree in that your comment that
> "conversion to cn=config" process isn't trivial, personally I get quite
> swamped by it, but push through as best I can. But if you're offering to
> convert my sample configs for me, I'd be happy to share them with you.
You can convert your sample configs via the slaptest command, as documented.
> Or
> perhaps you could help the community by providing some OLC config
> examples for the admin guide, that way us peons would be able to use that
> as our only official source instead of having to google to find "Random"
> help.
My point was more that converting examples in the admin guide from
slapd.conf to cn=config is fairly trivial.
For example, if we look at section 18.3.1.2 in the admin guide:
database mdb
maxsize 1073741824
suffix dc=Example,dc=com
rootdn dc=Example,dc=com
directory /var/ldap/db
index objectclass,entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
this is rather trivially converted to:
dn: olcDatabase={1}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcSuffix: dc=example,dc=com
olcRootDN: dc=example,dc=com
olcDbDirectory: /var/ldap/db
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
etc. Converting to cn=config from slapd.conf is not particularly difficult.
> I *can* move to refreshAndPersist; but the service provides two
> documented options (information I got from reading the admin guide), the
> description for refreshOnly best fits my scenario and needs. I didn't
> read any reason as to *not* use - perhaps you're aware of a bug report
> that refreshOnly is broken?
I'm aware that operating in refreshOnly is problematic, and it is advise
not to use it. If you want to persist in using it, I certainly can't stop
you. ;) If/when I find time to rewrite the admin guide, removing it from
the examples will be one of the first steps I take.
> Perhaps my research (which I'm sure isn't as broad as yours) just seemed
> to point to the fact that openldap will/may be depreciating the
> slapd.conf procedures, and that everyone should get on board with OLC as
> soon as possible. While I can perform the setup with slapd.conf (as noted
> in the admin guide), I was hoping to practice some useful technique I
> could use in the future.
Again, as noted in the documentation, you can set up one time with
slapd.conf, and then move forward with converting it to cn=config via
slaptest, and then just use cn=config from that point forward, using ldap*
commands to make updates as necessary.
If you want some further examples of cn=config, you may like the following:
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/conf/ldap/config/>
Which has a basic cn=config layout for a standalone server with a suffix of
"" and a few overlays loaded as a starting point.
You may also be interested in the tools I wrote for manipulating cn=config
to use as examples:
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldape...>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldape...>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapr...>
<https://git.zimbra.com/repos/zimbra-foss/ZimbraServer/src/libexec/zmldapm...>
etc. While bits of it are specific to Zimbra, the ideas behind
updating/modifying cn=config are universal.
On the documentation, I would note that it is a community effort, and
anyone can contribute updates, etc, via the ITS system. The sad fact is,
many people complain about the documentation, but very few ever step up and
contribute back, which means that it often languishes.
I hope the above helps.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
