DNS/ldap
by pascal.jakobi＠gmail.com
Just a question (quick).
You probably saw the relatively new CAA record for DNS. This (great) record provides a means to get the address of a CA for a given DNS domain.
Firstly, it is unclear to me why the old SRV records are not used as they essentially do the same. You may think of creating an SRV record for _pkica.<domain> that would provide a CA's IP address.
Then my question is : why is this SRV not used on linux boxes ? This would provide a means to retrieve automatically a certificate/public key for a given user and avoid setting configs (i.e. ldap.conf) on the client side. In other tertms, don't we need a CAA equivalent for Directories ?
1 year, 1 month
Error when running make test or slapd after building on windows
by Joshua Dunbar
Hello,
I am attempting to install openldap (latest version 2.6.1) on windows using Cygwin where I have installed dependencies of gcc core and make in order to get configure to run. I then run configure from a Cygwin terminal (without any arguments). Configure seems to run fine, and so does make depend, and make. Then when I attempt to run make test (or slapd with any other well formatted slapd.conf file) I get the following error message. I have turned on the highest level of logging and don't get any additional useful information and have been going at this for a couple days now without any luck. I have tried manipulating permissions on the db folder as well as using different folder names and locations. I can see the lock.mdb file being generated in the /tests/testrun/db.1.a folder, but nothing else. Any insight or help would be very appreciated.
620dab00.2d2e09dc 0x800000010 config_build_entry: "olcDatabase={2}monitor"
620dab00.2d2e359c 0x800000010 slap_get_csn: conn=-1 op=0 generated new csn=20220217015512.758001Z#000000#000#000000 manage=0
620dab00.2d2ecdf4 0x800000010 backend_startup_one: starting "o=OpenLDAP Project,l=Internet"
620dab00.2d2edba0 0x800000010 mdb_db_open: "o=OpenLDAP Project,l=Internet"
620dab00.2d3072a8 0x800000010 mdb_db_open: database "o=OpenLDAP Project,l=Internet": dbenv_open(/tests/testrun/db.1.a).
620dab00.2d3a1894 0x800000010 mdb_db_open: database "o=OpenLDAP Project,l=Internet" cannot be opened: Invalid argument (22). Restore from backup!
620dab00.2d3a37d4 0x800000010 backend_startup_one (type=mdb, suffix="o=OpenLDAP Project,l=Internet"): bi_db_open failed! (22)
620dab00.2d3a42c4 0x800000010 slapd shutdown: initiated
620dab00.2d3c25f8 0x800000010 slapd destroy: freeing system resources.
620dab00.2d5278d0 0x800000010 slapd stopped.
Thanks,
Josh
1 year, 1 month
Re: How to restrict access to pwdHistory attributes
by Chandeshwar Mishra
Hi Quanah,
Thanks for your response. Our setup is a very old one and we are planning
to migrate it to the latest stable version but Since this openldap is
deployed in Production
it is not possible for us to upgrade it suddenly.
As you mentioned that ppolicy schema is missing in configuration, so is it
possible that without having ppolicy schema, Openldap will remember the
pwdHistory of the user ?
In my case pwdHistory is visible to users, for which I want to apply ACL so
that a user can only see his/her pwdHistory , not other users pwdHistory.
Below are my configuration related to ppolicy configuration in config file:-
include /etc/openldap/schema/ppolicy.schema
--- more include directive related to schema
----
moduleload ppolicy.la
moduleload memberof.la
overlay memberof
overlay syncprov
overlay auditlog
#overlay accesslog
overlay ppolicy
ppolicy_default "cn=passwordDefault,dc=example,dc=com"
Thanks & Regards,
Chandeshwar Kumar
On Mon, Feb 14, 2022 at 11:24 PM Quanah Gibson-Mount <quanah(a)fast-mail.org>
wrote:
>
>
> --On Saturday, February 12, 2022 5:22 AM +0000
> kumarchandeshwar99(a)gmail.com
> wrote:
>
> > Hi,
> > I am trying to restrict access to pwdHistory attributes provided by
> > ppolicy overlay. I have applied the below ACL
> >
> > access to attrs=pwdHistory
> > by * none
> > but while doing slaptest, its throwing below error:-
> > /etc/openldap/slapd.conf: line 212: unknown attr "pwdHistory" in to
> clause
> > <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control>
> > ] ]+ <what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>]
> > [attrs=<attrspec>] <attrspec> ::= <attrname>
> > [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> <attrlist> ::=
> > <attr> [ , <attrlist> ]
> > <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry |
> children
> > <who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ]
> > [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN>
> ]
> > [dnattr=<attrname>]
> > [realdnattr=<attrname>]
> > [group[/<objectclass>[/<attrname>]][.<style>]=<group>]
> > [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>]
> > [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>]
> > [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>]
> >
> > Before posting here I searched archive and found one similar, issue , but
> > it did not resolve my issue. I have running openldap-servers-2.4.23 on
> > RHEL-6.5.
>
> You are missing the ppolicy schema in your configuration.
>
> However, I would note that both RHEL6 and OpenLDAP 2.4 are historic and no
> longer in support. I'd strongly advise upgrading to both an OS that is
> under support and a version of OpenLDAP that's under support.
>
> Regards,
> Quanah
>
>
>
>
1 year, 1 month
Re: OpenLDAP and NTLM
by Marc Boorshtein
>
>
>
> NTLM has been obsoleted and shouldn't be used at all. SASL/GSSAPI or
> SASL/GSS-SPNEGO should be fine.
>
I understand, but this is a legacy (really legacy) application that can't
be changed. Is NTLM still working?
>
1 year, 1 month
OpenLDAP and NTLM
by Marc Boorshtein
I see that NTLM is supported as an authentication mechanism for
supportedSASLMechanisms, but I'm not seeing any docs. Do I configure
GSSAPI and NTLM is now available?
Thanks
Marc
1 year, 1 month
slapo-memberof -> slapo-dynlist and value-based ACLs
by Michael Ströder
HI!
I'm experimenting to replace slapo-memberof to slapo-dynlist in Æ-DIR's
slapd.conf.
Ok, basically it works but...
Æ-DIR trys hard to follow need-to-know-principle. This means that
memberOf values are only made visible to clients which they have defined
to be visible on.
Thus I have ACLs like this and which don't work for these clients (lines
wrapped):
access to
dn.subtree="ou=ae-dir"
filter="(objectClass=posixAccount)"
attrs=memberOf
val.regex="^.+$"
[..]
by set.expand="(user/-1 | user/aeSrvGroup | user/-1/aeProxyFor) &
[ldap:///ou=ae-dir?entryDN?sub?(&(objectClass=aeSrvGroup)(aeStatus=0)(aeVisibleGroups=${v0}))]/entryDN"
read
[..]
by * none
I'm aware that this is quite special. But is there any chance that
something like this will be ever supported?
The alternative would be to implement an external update process for
maintaining 'memberOf'. :-/
Ciao, Michael.
1 year, 1 month
How to restrict access to pwdHistory attributes
by kumarchandeshwar99＠gmail.com
Hi,
I am trying to restrict access to pwdHistory attributes provided by ppolicy overlay.
I have applied the below ACL
access to attrs=pwdHistory
by * none
but while doing slaptest, its throwing below error:-
/etc/openldap/slapd.conf: line 212: unknown attr "pwdHistory" in to clause
<access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+
<what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>]
<attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist>
<attrlist> ::= <attr> [ , <attrlist> ]
<attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children
<who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ]
[ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ]
[dnattr=<attrname>]
[realdnattr=<attrname>]
[group[/<objectclass>[/<attrname>]][.<style>]=<group>]
[peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>]
[domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>]
[ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>]
Before posting here I searched archive and found one similar, issue , but it did not resolve my issue.
I have running openldap-servers-2.4.23 on RHEL-6.5.
If any further details requires , Please let me know.
Thanks.
1 year, 1 month
issue with importing the samba3 schema
by Ulf Volmer
Hello,
I'm trying to migrate an old openldap installation to a new one.
OS of the new one is SLES15SP3, we are using the symas 2.5 packages.
Sadly I got an error by importing the samba3 schema:
# /opt/symas/bin/ldapadd -Y EXTERNAL -H ldapi:/// -f
/opt/symas/etc/openldap/schema/samba3.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=samba3,cn=schema,cn=config"
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification
allowed
I'm able to import other schemas in the same way, si I don't think that
I hold the tool in the wrong way.
Any pointers for me?
Best regards
Ulf
1 year, 1 month
log analysis tools
by Paul B. Henson
Does anybody know of any good tools that can rip through an openldap log
file and analyze it, creating a report of what queries are being made
and how long they are taking to process?
All of the information I'm interested in is included in the log:
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 ACCEPT from
IP=134.71.247.28:46592 (IP=0.0.0.0:636)
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 BIND
dn="cn=it_boomi,ou=user,ou=service,dc=cpp,dc=edu" method=128
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 BIND
dn="cn=it_boomi,ou=user,ou=service,dc=cpp,dc=edu" mech=SIMPLE bind_ssf=0
ssf=256
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=0 RESULT tag=97 err=0
qtime=0.000031 etime=0.000189 text=
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SRCH
base="ou=user,dc=cpp,dc=edu" scope=2 deref=3
filter="(&(objectClass=person)(calstateEduPersonEmplID=014532336))"
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SRCH attr=memberOf
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=2 UNBIND
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 op=1 SEARCH RESULT
tag=101 err=0 qtime=0.000016 etime=0.192994 nentries=1 text=
Feb 4 18:23:54 ldap-01 slapd[1207]: conn=46272 fd=84 closed
but split up into a number of different lines which need to be
correlated to summarize it. Before I try it myself I was hoping somebody
else had already scratched that itch :). The only things I can find
searching are either really old or commercial products.
Thanks much…
1 year, 1 month
intermittent memberOf performance issues
by Paul B. Henson
I've run into another problem with the memberOf implementation on my 2.5
servers. After I sorted out the proper configuration, queries requesting
memberOf were very performant:
Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SRCH
base="ou=user,dc=cpp,dc=edu" scope=2 deref=3
filter="(&(objectClass=person)(calstateEduPersonEmplID=013522522))"
Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SRCH attr=memberOf
Feb 4 13:26:44 ldap-01 slapd[1207]: conn=23393 op=1 SEARCH RESULT
tag=101 err=0 qtime=0.000015 etime=0.191860 nentries=1 text=
However, intermittently the server gets into a state where the exact
same query takes over 30 seconds:
Feb 4 08:05:11 ldap-01 slapd[1425456]: conn=40797 op=1 SRCH
base="ou=user,dc=cpp,dc=edu" scope=2 deref=3
filter="(&(objectClass=person)(calstateEduPersonEmplID=015559557))"
Feb 4 08:05:11 ldap-01 slapd[1425456]: conn=40797 op=1 SRCH attr=memberOf
Feb 4 08:05:50 ldap-01 slapd[1425456]: conn=40797 op=1 SEARCH RESULT
tag=101 err=0 qtime=0.000019 etime=39.435523 nentries=1 text=
When this occurs, the only way to resolve the issue that I have found is
to reboot the server. Simply restarting slapd results in the same
degraded performance on these queries.
Normally there is very low read I/O load on the servers during
operation, probably averaging less than 1M/s, peaking up to maybe
20-30M/s for just an instant occasionally. When the memberOf query
performance is degraded, there is a very high read I/O load on the
server, continuously about 200-300M/s.
Any thoughts on this? It seems like for some reason the server gets into
a state where it is not using the cache or memory map for doing the
search required to construct the memberOf results? But instead is doing
a full disk read of the entire database?
It's also weird that restarting the service is not resolve this, but
rebooting the server does. I'm not intimately familiar with the
internals of lmdb, is there some state that persists with the
environment or memory map in between service runs that is only cleared
by a reboot?
I initially thought I might have had a theory on it, relating to an
unrelated bug in RHEL 8.5 that broke the "needs-rebooting" command
resulting in servers not properly rebooting after kernel/library
updates. The most recent occurrence of this issue started up after such
an update without the required reboot, but upon reviewing historic
occurrences it has occurred at times that don't meet that criteria, so I
find myself clueless again as to what's going on.
Any advice on how to fix or do further debugging on this issue much
appreciated, thanks…
1 year, 1 month
