openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu
Hi Folks,
I am having troubles configuring openladp to my requirements.
I am setting up an openldap server running on solaris 10 x86 to use as
a ldap proxy authentication server.
My issue is that i cant get it to send authenticated simple binds to the
backend ldap system. I am running wireshark and when i ldapsearch direct to
the backend ldap i see a bind which looks like this :-
Lightweight-Directory-Access-Protocol
LDAPMessage bindRequest(1)
"cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple
messageID: 1
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com
authentication: simple (0)
simple: 384174656C73747261316732
However when i initiate an ldapsearch to my local solaris slapd and capture
the proxied backldap bind to the backend ldap system it looks like this :-
Lightweight-Directory-Access-Protocol
LDAPMessage bindRequest(1) "<ROOT>" simple
messageID: 1
protocolOp: bindRequest (0)
bindRequest
version: 3
name:
authentication: simple (0)
simple: <MISSING>
I am having trouble working out from the documentation if it should be
acl-bind or idassert-bind or some other option which influences the backend
bind. I have tried both those to no avail.
Here is the "database ldap" section from my slapd.conf
#######################################################################
# ldap database definitions
#######################################################################
database ldap
uri "ldap://backendldap.core.dir.mycompany.com"
suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com"
rootdn "dc=core,dc=dir,dc=mycompany,dc=com"
acl-bind bindmethod=simple
binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com"
credentials="password"
idassert-bind bindmethod=simple
binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com"
credentials="password"
overlay pcache
proxycache bdb 400 1 50 1200
directory /var/openldap-data
cachesize 10000
index cn,sn,uid pres,eq,sub
index objectclass eq
proxycachequeries 400
proxyattrset 0 uid mail cn sn givenName
proxytemplate (uid=) 0 600
proxytemplate (mail=) 0 600
proxytemplate (&(uid=)(mail=)) 0 600
Any help would be greatly appreciated
Regards Rep
10 years, 11 months
Schema-aware and OBSOLETE (was: (ITS#6151) Update cosine.schema to RFC 4524)
by Michael Ströder
Kurt,
following-up on openldap-technical since this is off-topic in ITS#6151.
Kurt Zeilenga wrote:
>
> On Apr 22, 2010, at 2:58 PM, Michael Ströder wrote:
>
>> Kurt Zeilenga wrote:
>>> One additional note, I generally would advise that a schema-aware client
>>> not alter it's update behavior of elements based upon whether said elements
>>> are active or inactive (OBSOLETE) in the schema.
>>
>> I disagree especially for cases when new data is added.
>
> I think you're trying to make the client far smarter than it really ought
> to be.
This general statement is pretty blurry without speaking about certain use-cases.
> If the clients configured to place say place element of data in attribute
> x, it shouldn't try to put it elsewhere. It should fail.
> While certainly one could design a client such as it could be configured
> with fallbacks for attributes, and fallback for fallbacks, etc., this is an
> unnecessarily complication IMO.
Who said that my or any other client is doing anything like this in case of
OBSOLETE schema elements? It would certainly be non-sense.
The only thing I'm trying to achieve is to guide the user in the UI not to get
frustrated by trial-and-error.
> Also, note that were a client to attempt the above, it could still fail due
> to an element being marked inactive between the time it read the schema and
> the time it tried the DIT update.
A client always have to implement proper error control even if the UI is
guiding the user along the subschema information.
>>> Instead, they should just
>>> try the update and, if it fails, report it as they normally would.
>>
>> Modifying existing data I first have to think about...
>>
>>> Handling the inactive condition locally hides the error from the directory
>>> administrator, who is likely relying on directory server logs to find
>>> applications which using inactive schema.
>>
>> Hmm, that's not the case with a schema-aware client anyway which guides the
>> user *not* to use OBSOLETE schema elements.
>
> I generally assume the user is not selecting which attribute to store some
> piece of information into. I assume the client been programmed to collect
> a piece of information and configured (or programmed) where to store it.
With web2ldap it's a mix of both:
One can pre-configure HTML templates per object class for input forms with
which the web2ldap admin specifies the descriptive labels around an input
field. With this you can hide which LDAP attribute the data is stored into.
But the user can also switch to table and LDIF input fields (and back to
tempating) when editing the data.
In the template and table input forms I'd like to grey out input fields where
the user's input would lead to a schema violation (OBSOLETE). E.g. it does not
make sense to present OBSOLETE object classes in the object class select form
when adding/modifying entries. It's similar to use slapo-allowed to only
display editable input fields of attributes a user is allowed to write to.
On the other hand web2ldap always trys to respect what's already present in
the entries. The paradigm is to be minimal invasive: Don't change anything
while modifying existing entries if the user did not explicitly change it.
> The client you refer to is what I would call an application-neutral LDAP
> directory administration tool. For such a tool, it might be reasonable to
> warn the user (whose generally an "administrator" of some sort as opposed
> to a "normal" user).
Even such a tool can have customization. The categories are not that sharp... ;-)
>> You're likely talking about
>> detecting pre-configured applications with hard-coded use of OBSOLETE object
>> classes and attribute types.
>> Most times these are not schema-aware at all.
>
> Well, pre-configured applications may be schema-aware but maybe not as
> fully as an LDAP directory administration tool might be. They might check
> that the element they were configured to use is appropriate for that use by
> examining its specification in the subschema.
Yes, there are things like this in web2ldap too for certain use-cases (e.g.
determining whether it works with MS AD while setting password attribute etc.).
But I was especially interested in discussing what's appropriate in case of
OBSOLETE schema descriptions.
Ciao, Michael.
10 years, 11 months
[Fwd: Support for ordering matching rules in extensible match filters?]
by deepee＠gmx.net
Hi,
first of all, please excuse me if I've hit the wrong openldap mailinglist.
My question below is related to section 4.1 of RFC4517 which says:
Servers that implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 4.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion
syntax of the matching rule is the same as the value syntax of the
attribute.
Could someone please explain to me why openldap currently doesn't
support for example 'caseIgnoreOrderingMatch' (which is listed in
section 4.2 of RFC4517) in extensible match filters? Of course I've seen
the two SHOULDs above - I just don't understand the openldap related
technical/design decision regarding the missing support and would be
very happy if someone could please explain this to me.
Another more common question but also related to my previous mail
(below): could someone please also tell me the RFC(s) in which the
evaluation of ordering matching rules (especially when used in
extensible match filters) is specified?
Thanks again!
Betreff: Support for ordering matching rules in extensible match filters?
Datum: Thu, 22 Apr 2010 11:18:35 +0200
Von: Daniel <deepee(a)gmx.net>
An: openldap-technical(a)openldap.org
Hi,
why doesn't slapd support ordering matching rules in extensible match
filters?
Does the small code enhancement for slapd's
generalizedTimeOrderingMatch() would make sense into the direction to
support ordering matching in extensible filters (in this particular case)?
Thanks a lot!
static int
generalizedTimeOrderingMatch(
int *matchp,
slap_mask_t flags,
Syntax *syntax,
MatchingRule *mr,
struct berval *value,
void *assertedValue )
{
struct berval *asserted = (struct berval *) assertedValue;
ber_len_t v_len = value->bv_len;
ber_len_t av_len = asserted->bv_len;
/* ignore trailing 'Z' when comparing */
int match = memcmp( value->bv_val, asserted->bv_val,
(v_len < av_len ? v_len : av_len) - 1 );
Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n",
value->bv_val, asserted->bv_val, match);
if ( flags & SLAP_MR_EXT ) {
Debug( LDAP_DEBUG_TRACE,
"gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0);
if ( match == -1 ) match = 0;
else if ( match == 0 ) match = 1;
} else {
Debug( LDAP_DEBUG_TRACE,
"gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0);
if ( match == 0 ) match = v_len - av_len;
}
Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n",
value->bv_val, asserted->bv_val, match);
*matchp = match;
return LDAP_SUCCESS;
}
10 years, 11 months
N-Way Replication noob questions
by Siddhartha Jain
Hi,
First, kudos to OpenLDAP team for the progress they have made with 2.4. I am returning to use OpenLDAP after nearly a decade and it is heartening to see all the new features even when going from 2.3 to 2.4 (As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x. RedHat might do it to push their own DS over OpenLDAP but why CentOS)?
1. From the OpenLDAP guide, I see that replication is setup to replicate both - config and information trees.
a. With each master having a unique "ServerID", does it mean that config replication won't overwrite certain attributes like ServerID?
b. How are multiple "ServerID" values handled when the replication config is introduced?
c. What about credentials used for rootDN of various databases? Do they get sync-ed too?
2. What is the best way to setup a new master with empty databases? Slapcat from an existing one and Slapdadd to the new one? Or, let replication take care of it? Network traffic issues aside, my point is how does timestamp matching work for non-existant objects (in the new master vs existing). Or, put differently, how is deletion vs new/empty database differentiated? Why wouldn't replication consider the non-existence of databases in the new master as all databases having been deleted?
3. From 18.2.2.3 of the Guide "Arguments against Multi-Master replication".
4. " If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem"
Care to expand on this, please?
5. " If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider"
How so? If all masters are sync-ed with NTP tighly, then shouldn't this issue take care of itself when a partitioned master(s) comes back online and reconnect.
Thanks,
- Siddhartha
10 years, 11 months
ppolicy in back_ldap?
by Tyler Gates
Hey guys,
I currently have a multi-master system setup with a back_ldap
proxying frontend. We are using ppolicy and it is loaded fine and
works on the two masters but I'm experiencing a little weirdness on
the proxy side. It works fine but when I implemented password
expirations the other day I keep seeing messages on the proxy like:
ppolicy_bind: Setting warning for password expiry for .... = 0 seconds
These entries should not be receiving any warning messages and I know
my settings are correct because if I redirect to one of the masters
the log output is what I expect. Also, if I run a perl script that
uses password policy controls and look for time_before_expiration, the
value is always 0 on the proxy while it is not even set if
pwdExpireWarning is not met or a sane value if it is on the masters.
After reading slapo-ppolicy it looks like maybe I should be setting
olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in
olcDatabase={1}ldap,cn=config to both masters but it spits at me every
time I try it. It also says a chain overlay should be set as well but
when I read slapo-chain its says: "It is useless in conjunction with
the slapd-ldap and slapd-meta backends because they already exploit
the libldap specific referral chase feature."
If I remove ppolicy overlay I don't see any of the values.
I need the proxy to be able to see these attributes (as in those
making queries to it) and not hammer my logs with incorrect messages.
Is it possible to make this work, am I doing some wrong?
Thanks for any help,
Tyler
--
Tyler Gates
Systems Administrator
Castle Branch Inc.
910-815-3880 ext 7230
tjgates(a)castlebranch.com
This e-mail message, including any attachments, may contain private,
confidential, and privileged information for the restricted use of the
intended recipient(s). If you are not the intended recipient(s), you
may NOT use, disclose, copy, or disseminate this information. Please
notify the sender by return e-mail of this misdirected correspondence
and destroy all copies of the original message including all
attachments.
Your cooperation is appreciated.
10 years, 12 months
Syncrepl TLS certificate verification - configurable
by Siddhartha Jain
Hi,
I have setup replication between two primary servers to use TLS.
The config says:
{0}rid=101 provider=ldap://pldap01.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem
{1}rid=102 provider=ldap://pldap02.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem
Replication works alright but logs show these lines on pldap01:
Apr 22 03:47:20 pldap01 slapd[3451]: conn=1089 fd=22 TLS established tls_ssf=256 ssf=256
Apr 22 03:47:20 pldap01 slapd[3451]: slap_client_connect: URI=ldap://pldap02.xyz.net Warning, ldap_start_tls failed (-11)
And, this on pldap02:
Apr 22 03:47:40 pldap02 slapd[2564]: conn=1096 fd=26 TLS established tls_ssf=256 ssf=256
Apr 22 03:47:51 pldap02 slapd[2564]: slap_client_connect: URI=ldap://pldap01.xyz.net Warning, ldap_start_tls failed (-11)
To be fair, the certificates are self-signed and don't match the DN but I am assuming that "starttls=yes" forces TLS and the consumers cannot default to plaintext. Right? If yes, does this mean that in syncrepl, tls use is hardcoded to verify certificates and fall back to non-verified TLS session if verification fails? Or, is this configurable meaning can I enforce verification (preferable in production)?
Thanks,
- Siddhartha
10 years, 12 months
RE: Implementing LDAP logging
by rahul.manchanda＠bt.com
Adding to the below I didn't compiled the LDAP with --enable-debug
during configuration time. Is that the reason it is not logging to the
logfile I mentioned in the ldap configuration?
This is the way I am specifying the logging info in the slapd.conf:
loglevel sync stats
logfile
/opt/software/openldap2.4.19/etc/openldap/logs/ldaplog-primary.log
Please suggest.
Regards
Rahul Manchanda
------------------------------------------------------------------------
----------------------------------
Andes , Selfcare Platform Build Team
tel: (+91) (20) 66018100 extn: 6178; e-mail:
rahul.manchanda(a)bt.com
Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
From: Manchanda,RK,Rahul,DKE C
Sent: Wednesday, April 21, 2010 3:03 PM
To: openldap-technical(a)openldap.org
Cc: Manchanda,RK,Rahul,DKE C
Subject: Implementing LDAP logging
Hi All,
Even on specifying the loglevel and logfile directives in the slapd.conf
ldap related logs are not being written to the file.
However separate auditlog file is getting created successfully and all
the update/delete/modify/insert operations are getting recorded
successfully over there.
I need to get the ldap related log file created as well but that is
something not happening. Also tried specifying the LOCAL4 feature in the
syslog.conf and restarted the system logging service but no luck with
that as well.
I don't want to put the logging options in the ldap start up command
line argument but want the log file created from configuration itself.
Can someone please suggest on this and also is there a way to implement
log rotation for the ldap log file through configuration itself then
that will be really helpful.
Many Thanks in advance.
Regards
Rahul Manchanda
------------------------------------------------------------------------
----------------------------------
Andes , Selfcare Platform Build Team
tel: (+91) (20) 66018100 extn: 6178; e-mail:
rahul.manchanda(a)bt.com
Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
10 years, 12 months
Support for ordering matching rules in extensible match filters?
by Daniel
Hi,
why doesn't slapd support ordering matching rules in extensible match
filters?
Does the small code enhancement for slapd's
generalizedTimeOrderingMatch() would make sense into the direction to
support ordering matching in extensible filters (in this particular case)?
Thanks a lot!
Cheers
Daniel
static int
generalizedTimeOrderingMatch(
int *matchp,
slap_mask_t flags,
Syntax *syntax,
MatchingRule *mr,
struct berval *value,
void *assertedValue )
{
struct berval *asserted = (struct berval *) assertedValue;
ber_len_t v_len = value->bv_len;
ber_len_t av_len = asserted->bv_len;
/* ignore trailing 'Z' when comparing */
int match = memcmp( value->bv_val, asserted->bv_val,
(v_len < av_len ? v_len : av_len) - 1 );
Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n",
value->bv_val, asserted->bv_val, match);
if ( flags & SLAP_MR_EXT ) {
Debug( LDAP_DEBUG_TRACE,
"gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0);
if ( match == -1 ) match = 0;
else if ( match == 0 ) match = 1;
} else {
Debug( LDAP_DEBUG_TRACE,
"gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0);
if ( match == 0 ) match = v_len - av_len;
}
Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n",
value->bv_val, asserted->bv_val, match);
*matchp = match;
return LDAP_SUCCESS;
}
10 years, 12 months
RE: Implementing LDAP logging
by rahul.manchanda＠bt.com
Hi All,
Can someone please suggest on the below query?
Regards
Rahul Manchanda
------------------------------------------------------------------------
----------------------------------
Andes , Selfcare Platform Build Team
tel: (+91) (20) 66018100 extn: 6178; e-mail:
rahul.manchanda(a)bt.com
Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
From: Manchanda,RK,Rahul,DKE C
Sent: Wednesday, April 21, 2010 4:28 PM
To: Manchanda,RK,Rahul,DKE C; 'openldap-technical(a)openldap.org'
Subject: RE: Implementing LDAP logging
Adding to the below I didn't compiled the LDAP with --enable-debug
during configuration time. Is that the reason it is not logging to the
logfile I mentioned in the ldap configuration?
This is the way I am specifying the logging info in the slapd.conf:
loglevel sync stats
logfile
/opt/software/openldap2.4.19/etc/openldap/logs/ldaplog-primary.log
Please suggest.
Regards
Rahul Manchanda
------------------------------------------------------------------------
----------------------------------
Andes , Selfcare Platform Build Team
tel: (+91) (20) 66018100 extn: 6178; e-mail:
rahul.manchanda(a)bt.com
Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
From: Manchanda,RK,Rahul,DKE C
Sent: Wednesday, April 21, 2010 3:03 PM
To: openldap-technical(a)openldap.org
Cc: Manchanda,RK,Rahul,DKE C
Subject: Implementing LDAP logging
Hi All,
Even on specifying the loglevel and logfile directives in the slapd.conf
ldap related logs are not being written to the file.
However separate auditlog file is getting created successfully and all
the update/delete/modify/insert operations are getting recorded
successfully over there.
I need to get the ldap related log file created as well but that is
something not happening. Also tried specifying the LOCAL4 feature in the
syslog.conf and restarted the system logging service but no luck with
that as well.
I don't want to put the logging options in the ldap start up command
line argument but want the log file created from configuration itself.
Can someone please suggest on this and also is there a way to implement
log rotation for the ldap log file through configuration itself then
that will be really helpful.
Many Thanks in advance.
Regards
Rahul Manchanda
------------------------------------------------------------------------
----------------------------------
Andes , Selfcare Platform Build Team
tel: (+91) (20) 66018100 extn: 6178; e-mail:
rahul.manchanda(a)bt.com
Address: Tech Mahindra, Sharada Center, Erandwana Pune-4
10 years, 12 months
Help with objectClass and attribute definition.
by Techie
Hello,
I am looking to add attributes containing server names to my ldap accounts.
Does anyone know of an existing LDAP objectClass that will allow
multiple attribute definitions that can be used for server names.
For example..
objectClass: Servers
sharebox: homeserver.example.com
sharebox: dataserver.example.com
I would really like to avoid creating my own objectClass and attribute
definitions as I am sure some already exist.
Thank you
10 years, 12 months
