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
6 years, 6 months
Virtual list view problem
by Venish Khant
Hi all
I am using cpan Net::LDAP module to access LDAP entries. I want to
search LDAP entries using Net::LDAP search method. When I do search, I
want some limited number of entries from search result, for
this(searching) process I am using Net::LDAP::Control::VLV module. But
I get error on VLV response control. Please, any one have idea about
this error.
*
Error:* Died at vlv.pl line 50,
This is my example. I changed the font style of line 50
#!/usr/bin/perl -w
use Net::LDAP;
use Net::LDAP::Control::VLV;
use Net::LDAP::Constant qw( LDAP_CONTROL_VLVRESPONSE );
use Net::LDAP::Control::Sort;
sub procentry {
my ( $mesg, $entry) = @_;
# Return if there is no entry to process
if ( !defined($entry) ) {
return;
}
print "dn: " . $entry->dn() . "\n";
@attrs = $entry->attributes();
foreach $attr (@attrs) {
#printf("\t%s: %s\n", $attr, $entry->get_value($attr));
$attrvalue = $entry->get_value($attr,asref=>1);
#print $attr.":". $entry->get_value($attr)."\n";
foreach $value(@$attrvalue) {
print "$attr: $value\n";
}
}
$mesg->pop_entry;
print "\n";
}
$ldap = Net::LDAP->new( "localhost" );
# Get the first 20 entries
$vlv = Net::LDAP::Control::VLV->new(
before => 0, # No entries from before target entry
after => 19, # 19 entries after target entry
content => 0, # List size unknown
offset => 1, # Target entry is the first
);
my $sort = Net::LDAP::Control::Sort->new( order => 'cn' );
@args = ( base => "dc=example,dc=co,dc=in",
scope => "subtree",
filter => "(objectClass=inetOrgPerson)",
callback => \&procentry, # Call this sub for each entry
control => [ $sort, $vlv ],
);
$mesg = $ldap->search( @args );
# Get VLV response control
*($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;*
$vlv->response( $resp );
# Set the control to get the last 20 entries
$vlv->end;
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mesg->control( LDAP_CONTROL_VLVRESPONSE ) or die;
$vlv->response( $resp );
# Now get the previous page
$vlv->scroll_page( -1 );
$mesg = $ldap->search( @args );
# Get VLV response control
($resp) = $mes
# Now page with first entry starting with "B" in the middle
$vlv->before(9); # Change page to show 9 before
$vlv->after(10); # Change page to show 10 after
$vlv->assert("B"); # assert "B"
$mesg = $ldap->search( @args );g->control( LDAP_CONTROL_VLVRESPONSE ) or
die;
$vlv->response( $resp );
--
Venish Khant
www.deeproot.co.in
6 years, 12 months
chaining for a single backend?
by Marc Patermann
Hi,
I want to activate chaining for a single backend.
The server is a replication consumer and has a few glued database backends.
Only one is containing linux accounts with ppolicy overlay.
This should use chaining to replicate the ppolicy changes which
otherwise stay local.
Can this be achieved?
Marc
7 years, 3 months
Re: [OpenLDAP][Authentication] SASL
by Timothy Keith
The first attempt fails :
ldapwhoami -v -ZZ -Y EXTERNAL
ldap_initialize( <DEFAULT> )
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
This also fails :
ldapsearch -LLL -Y EXTERNAL -H ldaps:/// -b "" -s base +
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
Tim
On Thu, Jan 21, 2016 at 7:43 PM, Sergio NNX <sfhacker(a)hotmail.com> wrote:
>> My scenario is relatively simple.
> Simple, but it doesn't work, right?
>
> Are you after something similar to the output below?
>
> ldapwhoami -v -ZZ -Y EXTERNAL
>
> SASL/EXTERNAL authentication started
> SASL username: 2.5.4.13=End User Certificate (OpenLDAP
> 2.4.43),2.5.4.5=1234-2015
> -UK,title=Mr,ou=Finance Department,o=MateAR.eu IT
> Solutions,l=Westminster,st=Lon
> don,c=GB,email=info(a)matear.eu,0.9.2342.19200300.100.1.1=Administrator,dc=EU,cn=A
> dministrator
> SASL SSF: 0
> dn:description=end user certificate (openldap
> 2.4.43),serialNumber=1234-2015-uk,
> title=mr,ou=finance department,o=matear.eu it
> solutions,l=westminster,st=london,
> c=gb,email=info(a)matear.eu,uid=administrator,dc=eu,cn=administrator
> Result: Success (0)
>
>
> ldapsearch -LLL -Y EXTERNAL -H ldaps:/// -b "" -s base +
>
> SASL/EXTERNAL authentication started
> SASL username: 2.5.4.13=End User Certificate (OpenLDAP
> 2.4.43),2.5.4.5=1234-2015
> -UK,title=Mr,ou=Finance Department,o=MateAR.eu IT
> Solutions,l=Westminster,st=Lon
> don,c=GB,email=info(a)matear.eu,0.9.2342.19200300.100.1.1=Administrator,dc=EU,cn=A
> dministrator
> SASL SSF: 0
> dn:
> structuralObjectClass: OpenLDAProotDSE
> configContext: cn=config
> monitorContext: cn=Monitor
> namingContexts: dc=my-domain,dc=com
> supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
> supportedControl: 2.16.840.1.113730.3.4.18
> supportedControl: 2.16.840.1.113730.3.4.2
> supportedControl: 1.3.6.1.4.1.4203.1.10.1
> supportedControl: 1.3.6.1.1.22
> supportedControl: 1.2.840.113556.1.4.319
> supportedControl: 1.2.826.0.1.3344810.2.3
> supportedControl: 1.3.6.1.1.13.2
> supportedControl: 1.3.6.1.1.13.1
> supportedControl: 1.3.6.1.1.12
> supportedExtension: 1.3.6.1.4.1.1466.20037
> supportedExtension: 1.3.6.1.4.1.4203.1.11.1
> supportedExtension: 1.3.6.1.4.1.4203.1.11.3
> supportedExtension: 1.3.6.1.1.8
> supportedFeatures: 1.3.6.1.1.14
> supportedFeatures: 1.3.6.1.4.1.4203.1.5.1
> supportedFeatures: 1.3.6.1.4.1.4203.1.5.2
> supportedFeatures: 1.3.6.1.4.1.4203.1.5.3
> supportedFeatures: 1.3.6.1.4.1.4203.1.5.4
> supportedFeatures: 1.3.6.1.4.1.4203.1.5.5
> supportedLDAPVersion: 3
> supportedSASLMechanisms: SRP
> supportedSASLMechanisms: SCRAM-SHA-1
> supportedSASLMechanisms: GSSAPI
> supportedSASLMechanisms: GSS-SPNEGO
> supportedSASLMechanisms: DIGEST-MD5
> supportedSASLMechanisms: EXTERNAL
> supportedSASLMechanisms: OTP
> supportedSASLMechanisms: CRAM-MD5
> supportedSASLMechanisms: NTLM
> supportedSASLMechanisms: LOGIN
> supportedSASLMechanisms: PLAIN
> entryDN:
> subschemaSubentry: cn=Subschema
>
7 years, 3 months
problem with slapadd in migrating LDAP servers
by k j
Hello to all.
My situation is the following.
Migrating from an older Suse server : # rpm -qa | grep -i openldap openldap2-2.4.12-7.19.1 openldap2-client-2.4.12-7.19.1
to a New RHEL 6.6 server: # rpm -qa |grep ldap mod_authz_ldap-0.26-16.el6.x86_64 sssd-ldap-1.11.6-30.el6_6.4.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 openldap-clients-2.4.39-8.el6.x86_64 openldap-2.4.39-8.el6.x86_64 openldap-servers-2.4.39-8.el6.x86_64 compat-openldap-2.3.43-2.el6.x86_64
My exported information looks to be in order, has 47,000 lines but when I try to import it I run into trouble.
ldapadd -x -D "cn=administrator,dc=mydomain,dc=com" -W -f nis.ldif.ldapDump
When prompted for a password I am using the password from the old server (Suse) and that fails, thinking that no password has been setup on the new server I tried an empty password and that also failed.
Next I tried setting a new password 'ldappasswd Testing123' but that gave a SASL failure GSSAPI error :( additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired)
Am I going down the wrong road or what?
Thanks for any help,KJ
7 years, 3 months
Re: Removing olcAccess entry
by Katherine Faella
On Tue, Jan 12, 2016 at 2:47 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>
wrote:
> --On Tuesday, January 12, 2016 2:38 PM -0500 Katherine Faella <kmf(a)uri.edu>
> wrote:
>
> Which is where I am having trouble. I believe that deleting the {0}
>> element should keep the {1} and move it up to the correct position.
>>
>
> I do this extensively, and it works fine. What OpenLDAP release are you
> on?
>
> --Quanah
>
>
>
I was afraid you were going to ask that. We are running the Redhat 6
supported 2.4.40-7.el6_7. We have a policy here of sticking with the
redhat supported releases of packages since our staff is so small.
I really need to resolve this for an important project here. Of course the
project is behind schedule and I am left with little time to get my stuff
working. I was hoping my syntax was just incorrect. The only other way I
can image fixing this is to revert to slapd.conf ....
I guess the good news is that my steps and syntax look okay to you. If you
have any other thoughts I would happily accept them.
Thanks,
Kathy
--
Katherine Faella tel: (401) 874-4469
Senior Technical Programmer kmf(a)uri.edu
University of Rhode Island
University Computing Systems(UCS)
210 Flagg Road
Kingston, Rhode Island
7 years, 3 months
Re: [OpenLDAP][Authentication] SASL
by Timothy Keith
My scenario is relatively simple. The user authentication and LDAP
directory for our local application is managed on corporate servers
for which we lack administrative rights. We wish to maintain a local
view of the LDAP directory for the information that our local
application requires, but not alter the user authentication on the
corporate servers.
Tim
On Thu, Jan 21, 2016 at 6:21 PM, Sergio NNX <sfhacker(a)hotmail.com> wrote:
>> I am new at LDAP , that is obvious I guess. But, I've been around Unix
>> for 30 years.
>
> Are we still having issues? We might be able to assist you if you describe
> your set up and your goal in more detail.
>
> Cheers,
>
> Ser.
>
>> Date: Thu, 21 Jan 2016 14:31:28 -0600
>> From: dwhite(a)cafedemocracy.org
>> To: timothy.g.keith(a)gmail.com
>> Subject: Re: pass-through authentication
>> CC: dwhite(a)cafedemocracy.org; openldap-technical(a)openldap.org
>>
>> You can view your config with:
>>
>> slapcat -n0
>>
>> And verify that object exists.
>>
>> If you're receiving this error due to an ACL problem, verify you
>> have the proper configuration in place to authenticate as the rootdn using
>> sasl/external. See the slapd-config manpage, and see section 15.2 (and in
>> particular 15.2.5) of the Administrator's guide, and reference your
>> OS/distro documentation.
>>
>> On 01/21/16 12:35 -0600, Timothy Keith wrote:
>> >I commented the mech_list in slapd.conf
>> >
>> >The ldapsearch result is now No such object
>> >
>> >ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config
>> >"(|(cn=config)(olcDatabase={1}hdb))"
>> >No such object (32)
>> >
>> >On Fri, Jan 8, 2016 at 2:34 PM, Dan White <dwhite(a)cafedemocracy.org>
>> > wrote:
>> >> On 01/07/16 17:24 -0600, Timothy Keith wrote:
>> >>>
>> >>> ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config
>> >>> "(|(cn=config)(olcDatabase={1}hdb))"
>> >>> ldap_sasl_interactive_bind_s: Authentication method not supported (7)
>> >>> additional info: SASL(-4): no mechanism available:
>> >>
>> >>
>> >> I'm missing some context here. Most likely you have a mech_list hard
>> >> coded
>> >> in your slapd.conf sasl, which does not include the external mech.
>>
7 years, 3 months
openldap and slapd.conf file
by Mary Kao
Hello,
I've seen information indicating that slapd.conf is no longer in use in OpenLDAP, however the release 2.4.xx comes with a slapd.conf.
Can someone please clarify what this file is used for in release 2.4.xx?
Would be greatly appreciated.
Thank you!
7 years, 3 months
Lastbind
by Lindolfo Meira
I noticed the lastbind module won't log public key authentications. Is this
the expected behavior? I'm using OpenLDAP 2.4.33.
Cheers,
L. Meira.
7 years, 4 months
