openldap-technical

openldap-technical@openldap.org

14 participants
9795 discussions

olcDbConnectionPoolMax documentation
by Jongeling, Eric C 21 Mar '19

21 Mar '19

I'm running into what appears to be an issue with my olcDatabase meta configuration that appears to be a bottleneck limiting me to 16 concurrent operations when working through the meta database. This seems suspiciously similar to the olcDbConnectionPoolMax setting I've seen in many examples and the value I usually encounter of 16. The schema definition doesn't clear it up entirely, either: olcAttributeTypes: ( OLcfgDbAt:3.23 NAME 'olcDbConnectionPoolMax' DESC 'Max size of privileged connections pool' SYNTAX OMsInteger SINGLE- VALUE ) While I assume that this sets the maximum size of the backend connection pool, I'm confused by the word "privileged" in this situation. Can someone explain what this setting controls or point me towards documentation? Thanks in advance! ~Eric C. J.

2 1

Replication and pwdAccountLockedTime
by Jochen Keutel 21 Mar '19

21 Mar '19

Hello, we are using OpenLDAP 2.4.44 on Debian 9 in a distributed scenario: push based replication (means: using proxies with ldap backend). All works fine, all attributes (normal and operational) are replicated. Only one problem occurs: - when we set pwdAccountLockedTime on the master it gets replicated without problems. - but if we remove this attribute on the master (means: we unlock the account) this change is NOT replicated: The attribute is still there in all replicas, so the accounts stay locked. Is this by design - or is it a bug? Regards Jochen.

2 1

Discarding unused(?) olcRootPW passwords
by Bob Hund 20 Mar '19

20 Mar '19

Hi, I inherited a slapd deployment which rebuilds instances from scratch via automation. All configuration is done by slapadd'ing ldifs when instances are stood up. We don't make configuration changes at run time. When we need to make a change we modify the automation scripts and standup new instances from scratch. I noticed that there are olcRootPW entries for the "cn=admin,cn=config" and "cn=admin,dc=ourcompany,dc=com" root DNs, in the configuration I inherited, but we don't ever use them explicitly. In fact the entries are hashes, and I can't even find any uses of the cleartext in our code. My gut feeling is that I should reset the hashes and discard the cleartext to prevent misuse of these credentials. Is there any reason not to do this? Thanks in advance for any insight you can provide.

3 2

Configuring Back-LDAP as proxy for MirrorMode nodes to ensure writes are always handled by the designated master
by George Diamantopoulos 20 Mar '19

20 Mar '19

Hello all, I've successfully set-up a 2-node LDAP cluster, where each node is a provider to the other according to section 18.3.4 of the Administrator's Guide. The next logical step is to implement Load-Balancer/Proxy entities, which will ensure that writes always go to the same node. So far my preliminary proxy configuration allows reading from the cluster successfully. Here are the relevant bits (LDIF whitespace manipulated for readability): dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to * by * write olcRootDN: cn=admin,dc=domain,dc=tld olcRootPW: {SSHA}s3krit olcSuffix: olcDbStartTLS: start olcDbURI: ldap://ldap1.domain.tld,ldap://ldap2.domain.tld I understand that this configuration will always use the first URI in olcDbURI unless there is a failure, in which case it will fall back to the second URI (apparently after a timeout, and will then use it for subsequent operations until that fails too). I'm happy with this, although if there were a way to perform round-robin between the two for read operations, it would be ideal (is there?). However, writes to the proxy won't work with this configuration. In the Administrator Manual it is stated that one should use the proxy "as a syncrepl provider", but I am not sure I understand how this is supposed to work. Am I supposed to add another olcSyncrepl attribute (there's already one for syncing the two MirrorMode nodes themselves) to the MirrorMode nodes pointing to the proxy? And if I have more than one proxy, should I add an olcSyncrepl attribute for each? And how do I ensure that only one of the MirrorMode nodes fetches data from the proxy provider(s) at any given time? I've spent quite some time googling this to no avail. Any insight would be greatly appreciated. Thank you! Best regards, George

2 2

Rsyslog stdout and stderr
by Abdelkader Chelouah 17 Mar '19

17 Mar '19

Hi, slapd 2.4.44 OpenLDAP instance configure as a proxy (back-ldap) >From time to time, bind operations can take more than 5 sec. These latencies do not seem to come from a CPU or memory problem. I'm trying to see if the network can be the root cause of the issue. To debug the fonction ldap_sasl_bind (libraries/libldap/sasl.c), I activated trace loglevel (logs are manage by rsyslog). In the definition of ldap_sasl_bind, there is Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); A least the message "ldap_sasl_bind" should appear in logs, which is not the case. Actually, Debug (which is first defined in include/ldap_log.h) is redefined in libraries/libldap/ldap-int.h ... #include "ldap_log.h" #undef Debug #ifdef LDAP_DEBUG #define DebugTest( level ) \ ( ldap_debug & level ) #define Debug( level, fmt, arg1, arg2, arg3 ) \ do { if ( ldap_debug & level ) \ ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ); \ } while ( 0 ) #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 )\ ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ) configure #else #define DebugTest( level ) (0 == 1) #define Debug( level, fmt, arg1, arg2, arg3 ) ((void)0) #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 ) ((void)0) #endif /* LDAP_DEBUG */ ... A a result, the message is send to standard output. By using rsyslog, it is not possible to catch any message inside ldap_sasl_bind. How to get stdout and stderr messages and still use rsyslog to manage openldap logs ? Thanks in advance.

3 3

How do I enable LDAP or OpenLDAP in Windows Server 2019 Active Directory Domain Services Domain Controller?
by Turritopsis Dohrnii Teo En Ming 14 Mar '19

14 Mar '19

Good morning from Singapore, How do I enable LDAP or OpenLDAP in Windows Server 2019 Active Directory Domain Services Domain Controller so that network devices like network security appliances/firewalls and network attached storages (NAS) are able to join the domain and obtain the list of Active Directory Users for authentication purposes? Thank you. ===BEGIN EMAIL SIGNATURE=== The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming ===END EMAIL SIGNATURE===

1 0

On pwdGraceUseTime granularity
by Matus Honek 13 Mar '19

13 Mar '19

Hello, currently, granularity of pwdGraceUseTime is one second. This allows client to successfully bind with old password as many times as they want during N seconds (where N is equal to pwdGraceAuthnLimit) which may be unwanted. Would it be possible to increase the granularity, and if so, what size would make sense? Could it be made configurable? FWIW, I know that basically every major LDAP server has one second granularity, and that this does not mitigate the actual issue (only lowers the time window during which this can be misused). Thanks and regards. -- Matúš Honěk Software Engineer Red Hat Czech

2 1

LDAP authentication with just sAMAccountName
by Florea, Cosmin Petre 12 Mar '19

12 Mar '19

Hello, I have a LDAP Linux client written with OpenLDAP and i need it to be able to authenticate a user only by username and password (no domain). By username i mean the sAMAccountName from the LDAP record. The bind succeeds if i use "username@domain" or if i use the userPrincipalName (which is not equal to sAMAccountName), but i am unable to make it work just with username. Anonymous ldap_bind followed by a ldap_search does not work (it works if the bind is not anonymous). I have also a windows client (not using openldap library) implemented with DirectoryEntry from C#. The login with just the username works fine in that implementation (connected to the same LDAP server). In the LDAP log file on Windows i see (i put [...] to hide the server address): <Data Name="Message">ldap_bind called for connection 0xd059b718: DN is (null). Method is 0x486. Synchronous is 0x1. <Data Name="Message">ldapBind found server is Windows 2003 or better AD on connection 0xd059b718 <Data Name="Message">Connection->hostname is '[.........]' <Data Name="Message">Connection->DnsSuppliedNAme is '[.........]' <Data Name="Message">Connection->DomainName is '(null)' <Data Name="Message">LDAP: make spn returned 'ldap/[.........]' with error 0 <Data Name="Message">ldapBind found GSSAPI auth type on connection 0xd059b718 <Data Name="Message">ldapBind found GSS-SPNEGO auth type on connection 0xd059b718 <Data Name="Message">ldapBind found DIGEST auth type on connection 0xd059b718 <Data Name="Message">ldap bind: Server is v3 <Data Name="Message">ldap bind: Server supports both GSS-SPNEGO and GSSAPI <Data Name="Message">New servicename for bind is 'ldap/[.........]' <Data Name="Message">wldap32:Server is capable of 'NTLM' <Data Name="Message">ldap_bind returned 0x0 for connection 0xd059b718. So on windows it does ldap_bind 2 times , but i think it is using a different mechanism, probably Windows specific (i mean not ldap_search) to retrieve the userPrincipalName associated with the sAMAccountName from input. I do not have an account that i can use to make the initial bind (my client should work with several distinct servers). My question is: how to do it on linux with OpenLDAP? Is it possible? Thank you.

2 2

Re: Antw: Expected operation of pwdFailureCountInterval
by Tom Jay 12 Mar '19

12 Mar '19

I think the documentation could do with being updated slightly. This is taken from the slapo-ppolicy manual: pwdFailureCountInterval This attribute contains the number of seconds after which old consecutive failed bind attempts are purged from the failure counter, even though no successful authentication has occurred. If pwdFailureCountInterval is not present, or its value is zero (0), the failure counter will only be reset by a successful authentication. What I think that means is that unless the account is locked, and there are no successful authentication attempts, failed bind attempts are cleared from the LDAP entry after the pwdFailureCountInterval time. If the account is locked, the pwdFailureTime entries remain until the account is unlocked manually (or the pwdLockoutDuration time) and a successful authentication attempt (if the account is not locked) will also clear the pwdFailureTime entries. Tom On 2019-02-28 15:00, Ulrich Windl wrote: >>>> Tom Jay <web(a)tomjay.co.uk> schrieb am 27.02.2019 um 04:05 in >>>> Nachricht > <19f2a950eb051ccafe5a4420752d8b84(a)tomjay.co.uk>: >> Hello, >> >> Can someone explain the expected operation of the >> pwdFailureCountInterval attribute please? The documentation seems to >> be >> fairly clear, but if I add it to the password policy, along with some >> other attributes, the account remains locked, even after the >> pwdFailureCountInterval time. Despite authenticating with a valid >> password, the pwdFailureTime entries remain and the account remains >> locked. > > I think the mechanism is the other way round: As long as the account > is not locked, failed counts are reset every (after?) 1200 seconds. > Once an account is locked, it stays locked. > > Did you look at pwdLockoutDuration? > > Regards, > Ulrich > >> >> These are the attributes in use: >> pwdLockout: TRUE >> pwdMaxFailure: 5 >> pwdFailureCountInterval: 1200 >> >> Thanks. >> >> Tom

1 0

Re: Rsyslog stdout and stderr
by albert de montreuil 12 Mar '19

12 Mar '19

Abdelkader Chelouah wrote: > > Hi, > > > > slapd 2.4.44 > > > > OpenLDAP instance configure as a proxy (back-ldap) > > > > > > From time to time, bind operations can take more than 5 sec. These latencies do not seem to come from a CPU or memory problem. I'm trying to see if the network > > can be the root cause of the issue. To debug the fonction ldap_sasl_bind (libraries/libldap/sasl.c), I activated trace loglevel (logs are manage by rsyslog). In > > the definition of ldap_sasl_bind, there is > > > > Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); > > > > A least the message "ldap_sasl_bind" should appear in logs, which is not the case. Actually, Debug (which is first defined in include/ldap_log.h) is redefined > > in libraries/libldap/ldap-int.h > > > > ... > > > > #include "ldap_log.h" > > > > #undef Debug > > > > #ifdef LDAP_DEBUG > > > > #define DebugTest( level ) \ > > ( ldap_debug & level ) > > > > #define Debug( level, fmt, arg1, arg2, arg3 ) \ > > do { if ( ldap_debug & level ) \ > > ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ); \ > > } while ( 0 ) > > > > #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 )\ > > ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ) > > configure > > #else > > > > #define DebugTest( level ) (0 == 1) > > #define Debug( level, fmt, arg1, arg2, arg3 ) ((void)0) > > #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 ) ((void)0) > > > > #endif /* LDAP_DEBUG */ > > > > ... > > > > A a result, the message is send to standard output. By using rsyslog, it is not possible to catch any message inside ldap_sasl_bind. > > > > > > How to get stdout and stderr messages and still use rsyslog to manage openldap logs ? > syslog is not fast enough to handle the debug traffic. > You could use ber_set_option() to override the log output functions, and have them write > messages both to rsyslog and stderr. But using syslog on every debug message will slow > things down more than 10x. Hi, I'am also interressed to enable stderr and stdout to rsyslog. I try to figure out how to use ber_set_option(), but i'am pretty sur i miss something in my analysis. Starting from the function ldap_sasl_bind in file libraries/libldap/sasl.c + Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); Debug is macro define in first place in include/ldap_log.h and override by libraries/libldap/ldap-int.h So Debug is replace by ldap_log_printf() which is defined in libraries/libldap/print.c, ldap_log_printf() make some check and get varargs and send to pointer function 'ber_pvt_log_print' ber_pvt_log_print is pointer to ber_error_print() in file libraries/liblber/bprint.c. So the target is to change ber_pvt_log_print In function ber_set_option() we can redefine the print function ber_pvt_log_print to write messages both to rsyslog and stderr. (in /servers/slapd/main.c) ber_set_option(NULL, LBER_OPT_LOG_PRINT_FN, &print_syslog); The function is pretty basic : void print_syslog( LDAP_CONST char *data ) { Log0(LDAP_DEBUG_ANY, ldap_syslog_level, data); return ; } Of course i declare prototype in header file. Is it what you have in mind or should i use a function in OpenLDAP ?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical