Reg OpenLdap on Ubuntu
by Asimananda Mohanty
Hi All,
I am currently busy configuring OpenLdap on my newly installed Ubuntu 9.04.
Here is what I have done till now.
I followed the steps defined in
https://help.ubuntu.com/8.10/serverguide/C/openldap-server.html and
installation was successful. I installed PhpLdapAdmin also.
After I created certificate, key etc, I created a .ldif file
(enable-ca.ldif) with the following content :
*dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.crt
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/server.key*
Then I executed the command :
*ldapmodify -D "cn=admin,cn=config" -x -w 12345678 -f enable-ca.ldif*
and it was a success.
But after this, when I tried to restart slapd, I got errors like the
following :
*main: TLS init def ctx failed: -1*
I noticed that after I executed "ldapmodify -D "cn=admin,cn=config" -x -w
12345678 -f enable-ca.ldif", 3 lines are added to
/etc/ldap/slapd.d/cn=config.ldif
and when I commented the last two lines like the following, slapd started
successfully.
*olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
#olcTLSCertificateFile: /etc/ssl/certs/server.crt
#olcTLSCertificateKeyFile: /etc/ssl/private/server.key*
This looks quite strange.
Please help me resolving the same.
-Asimananda
13 years, 8 months
Forced password change not allowed
by mlb＠imparisystems.com
I've got openLDAP running and installed the pam and nss libraries so it
would also control the Linux passwords. I'm trying to sign onto my server
using ssh - but once I enter my username and password, I get
WARNING: Your password has expired.
You must change your password now and login again!
Enter login(LDAP) password:
Now being a bad security person, I always use the exact same username /
password combination and they don't work.
If a use either nothing (just hit Enter) or if I put in the standard
password I get
passwd: Authentication information cannot be recovered
passwd: password unchanged
Connection to ubuntu closed.
If I enter in some nonsensical string I get
LDAP Password incorrect: try again
Enter login(LDAP) password:
However, that is the only root level user on the machine and I have TONS of
stuff on it. How do I fix? Is this an openLDAP issue or something else?
Thanks
13 years, 8 months
SASL LDAP binding over IPv6
by Xu, Qiang (FXSGSC)
Hi, all:
In using ldapsearch to bind to a server with IPv6 address, some error pops up:
===========================================================
qxu@durian(pts/3):/etc[133]$ kinit XCTEST100(a)XCIPV6.COM Password for XCTEST100(a)XCIPV6.COM:
qxu@durian(pts/3):/etc[134]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: XCTEST100(a)XCIPV6.COM
Valid starting Expires Service principal
06/09/09 17:35:18 06/10/09 03:34:41 krbtgt/XCIPV6.COM(a)XCIPV6.COM
renew until 06/10/09 17:35:18
qxu@durian(pts/3):/etc[135]$ ldapsearch -Y GSSAPI -H 'ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail
Could not create LDAP session handle for URI=ldap://3ffe:2000:0:1:e0be:1872:d4f8:6b2c (-9): Bad parameter to an ldap routine
qxu@durian(pts/3):/etc[136]$ ldapsearch -Y GSSAPI -H 'ldap://[3ffe:2000:0:1:e0be:1872:d4f8:6b2c]' -b 'dc=xcipv6,dc=com' -s sub -LLL 'cn=XCTEST100' mail
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
===========================================================
Shall I add the brackets [] around the IPv6 address? DNS server has been correctly set up, because sasl binding over IPv4 address is good.
Any possible reason for the failure of ldapsearch?
Thanks,
Xu Qiang
13 years, 9 months
force creation of a "glue" node in the database?
by Robert Hanson
Using 2.4.16 on RedHat Linux. Does anyone know of a way to force the creation of a "glue" node in ldap?
Here is the scenario:
For some (as yet unknown) reason, our database sometimes has "glue" nodes. I'm suspecting this relates to syncrepl, but have not been able to diagnose the problem yet. I'm working on adding the manageDSAit control to our server requests (using the c client interface). I'd like a way to test this automatically. One way to do that would be to have the test program create a "glue" node and see that it can be found by the client code.
I can't find a way to get the glue node created; I'm always getting a error 65 invalid structural object class chain.
13 years, 10 months
lastmod in slapd.conf
by Srinidhi Sharma
Hi,
Is it possible to detect using JNDI api's if the lastmod is turned on in
Open-ldap slapd.conf file ?
any pointers would be helpful.
--
Thanks,
Srinidhi
13 years, 10 months
RE: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
by Robert Hanson
What I need is to have the "glue" items returned as part of the search. It looks to me like I can get nodes that are "glue" nodes to be part of the results by commenting out these lines:
in src\servers\slapd\back-bdb\search.c, lilnes 908-91
if ( !manageDSAit && is_entry_glue( e )) {
goto loop_continue;
}
If I comment out these lines, then I get the results I'm looking for.
Are there any other implications to the "glue" nodes? It looks like I'm able to edit and delete these nodes as well. But there is code in delete.c, modify.c, modrdn.c that worry about glue nodes.
Another option would be to redefine the is_entry_glue macro to always return false. Is that a better approach?
________________________________
From: Robert Hanson
Sent: Thursday, July 30, 2009 11:08 AM
To: 'openldap-technical(a)openldap.org'
Subject: entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
Is this bug ITS#4626? Or is there a workaround?
====
Using a build of 2.4.16 on RedHat linux; in a multi-master environment with 2 nodes. On both nodes, I have a tree that has a node "ou=Company, o=MyCompanyName". Under that are several nodes that are "glue" nodes. Following those is a actual data node.
Slapd 2.4.16, built from source, running on redhat linux)
I have seen this occur several times on various test systems with similar configurations.
The data in these nodes is inserted, in the proper order, (parent then children) using ldap client calls (ldap_add_s). Later, when I go to look at the output of slapcat, I see that some nodes are replaced with "glue" nodes.
Questions:
1) Why are these glue nodes created? Is there a known bug that will cause existing nodes to be deleted without the children being deleted? Is this an issue in replication? (where syncrepl needs to create a node where the parent does not exist). Is that why the glue nodes are created later?
2) How can I change the "glue" to some other class? Can that be done programmatically?
3)
========
This is a dump of slapcat (with unnecessary nodes removed)
dn: o=MyCompanyName
objectClass: organization
o: MyCompanyName
structuralObjectClass: organization
entryUUID: feb5b352-2eb7-102d-8c1f-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.418938Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
contextCSN: 20090728202448.877262Z#000000#001#000000
contextCSN: 20090728202123.336320Z#000000#002#000000
dn: ou=Company,o=MyCompanyName
ou: Company
description: 3.0.0
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: feb7a41e-2eb7-102d-8c28-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.432024Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
dn: lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 0136f8e0-0ff7-102e-8da5-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Servers,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 014e7632-0ff7-102e-8db3-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Application Data,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: e5a152de-0fff-102e-923c-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: appName=Configurations,ou=Application Data,lcc=Call Center 1,ou=Company,o=
MyCompanyName
entryUUID: e5a299f0-0fff-102e-923d-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
structuralObjectClass: applicationUnit
appName: Configurations
objectClass: applicationUnit
entryCSN: 20090728202143.649526Z#000000#001#000000
modifiersName: cn=Client,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202143Z
13 years, 10 months
entries exist in ldap (as glue entries), but are missing from the tree (v2.4.16)
by Robert Hanson
Is this bug ITS#4626? Or is there a workaround?
====
Using a build of 2.4.16 on RedHat linux; in a multi-master environment with 2 nodes. On both nodes, I have a tree that has a node "ou=Company, o=MyCompanyName". Under that are several nodes that are "glue" nodes. Following those is a actual data node.
Slapd 2.4.16, built from source, running on redhat linux)
I have seen this occur several times on various test systems with similar configurations.
The data in these nodes is inserted, in the proper order, (parent then children) using ldap client calls (ldap_add_s). Later, when I go to look at the output of slapcat, I see that some nodes are replaced with "glue" nodes.
Questions:
1) Why are these glue nodes created? Is there a known bug that will cause existing nodes to be deleted without the children being deleted? Is this an issue in replication? (where syncrepl needs to create a node where the parent does not exist). Is that why the glue nodes are created later?
2) How can I change the "glue" to some other class? Can that be done programmatically?
3)
========
This is a dump of slapcat (with unnecessary nodes removed)
dn: o=MyCompanyName
objectClass: organization
o: MyCompanyName
structuralObjectClass: organization
entryUUID: feb5b352-2eb7-102d-8c1f-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.418938Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
contextCSN: 20090728202448.877262Z#000000#001#000000
contextCSN: 20090728202123.336320Z#000000#002#000000
dn: ou=Company,o=MyCompanyName
ou: Company
description: 3.0.0
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: feb7a41e-2eb7-102d-8c28-f1b463e2c47e
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20081015034921Z
entryCSN: 20081015034921.432024Z#000000#000#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20081015034921Z
dn: lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 0136f8e0-0ff7-102e-8da5-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Servers,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: 014e7632-0ff7-102e-8db3-59a5102cad9a
creatorsName: cn=Client,ou=People,o=MyCompanyName
createTimestamp: 20090728191715Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: ou=Application Data,lcc=Call Center 1,ou=Company,o=MyCompanyName
entryUUID: e5a152de-0fff-102e-923c-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
objectClass: top
objectClass: glue
structuralObjectClass: glue
entryCSN: 20090728202123.336320Z#000000#002#000000
modifiersName: cn=MyDivision,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202123Z
dn: appName=Configurations,ou=Application Data,lcc=Call Center 1,ou=Company,o=
MyCompanyName
entryUUID: e5a299f0-0fff-102e-923d-cf0948a0ceb1
creatorsName: cn=MyDivision,ou=People,o=MyCompanyName
createTimestamp: 20090728202054Z
structuralObjectClass: applicationUnit
appName: Configurations
objectClass: applicationUnit
entryCSN: 20090728202143.649526Z#000000#001#000000
modifiersName: cn=Client,ou=People,o=MyCompanyName
modifyTimestamp: 20090728202143Z
13 years, 10 months
Radius authentication and storing passwords in cleartext
by Eric Bourkland
I have zimbra openLDAP v2.3.43 running on RHEL4.7 ES and I am trying to connect our freeRadius server to authenitcate against LDAP. I have also being trying to stand up plane openLDAP v2.4.17 to see if I can get that to work.
Free Radius requires PEAP/CHAPv2 to authenticate, which means it needs to be handed a clear text password in order to work. Yes, I know in general this is not a good idea.
How can I configure openLDAP to store passwords (userpassword attribute) in cleartext.
Or at the very least create a script that will be able to take the encrypted password and store it in cleartext as another attribute.
Thanks,
13 years, 10 months
Member-of plugin support for nested membership
by Mathias Gug
Hi,
While discussing the possibility of using openldap in place of 389
directory in the FreeIPA project [1] the following technical detail was
mentioned.
[1]: https://www.redhat.com/archives/freeipa-devel/2009-July/msg00333.html
According to the memberof overlay man page:
The memberof overlay to slapd(8) allows automatic reverse group member‐
ship maintenance. Any time a group entry is modified, its members are
modified as appropriate in order to keep a DN-valued "is member of"
attribute updated with the DN of the group.
Does the memberOf overlay deal with nested membership? Or is it
strictly a 1:1 relationship (forward pointer, reverse pointer)?
The 389 memberOf plug-in maintains reverse pointers for inherited
membership which IPA takes advantage of.
--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com
13 years, 10 months
Re: get_ava: illegal value with translucent proxy
by Petteri Heinonen
Pierangelo Masarati [masarati(a)aero.polimi.it] kirjoitti:
> Petteri Heinonen wrote:
> > Pierangelo Masarati [masarati(a)aero.polimi.it] wrote:
> >> Petteri Heinonen wrote:
> >> > Hi, I've setup a translucent proxy. Now, I have tried to do some
> >> test > searches. For example this works ok:
> >> > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b >
> >> "OU=Users,OU=Department,DC=company,DC=com" "(givenName=Myname)"
> >> > > Search is proxied through proxy to the actual server, and correct
> >> result > is returned. However, if I try this:
> >> > > ldapsearch -x -W -D "cn=admin,dc=company,dc=com" -b >
> >> "OU=Users,OU=Department,DC=company,DC=com" "(objectClass=User)"
> >> > > I get no results. I have monitored the traffic between proxy and
> >> backend > server, and the query is not even sent there. In OpenLDAP
> >> log there is:
> >> > > Jul 27 15:51:00 ldaptr01 slapd[17772]: begin get_filter
> >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: EQUALITY
> >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: get_ava: illegal value for >
> >> attributeType objectClass
> >> > Jul 27 15:51:00 ldaptr01 slapd[17772]: end get_filter 0
> >> > > What would be the problem here?
> >>
> >> The objectClass "User" is not defined in the proxy's schema?
> >>
> >> p.
> >>
> >
> > That's correct. But in translucent overlay's documentation, there is:
> >
> > "Note: The Translucent Proxy overlay will disable schema checking in the
> > local database, so that an entry consisting of overlay attributes need
> > not adhere to the complete schema."
> >
> > But it seems that schema checking is still in affect when doing
> > searches. Is there a way to disable local schema checking altogether? Or
> > do I have to build some dummy schema so that OpenLDAP is aware about
> > objectClasses I want to search for?
>
> What happens is that you use unknown schema items in the *filter*, which
> requires it to be known in order to apply appropriate matching rules and
> so. The schema relaxation in the documentation refers to enforcing
> adherence with allowed and required attributes of an objectclass, and
> with stored objectclasses complying with structural inheritance
> relationship. Schema items need to be known anyway.
>
> p.
>
Ok, thanks for the clarification. I guess that my goal to have an Active Directory proxied properly is not going to happen. I would need a complete AD schema for OpenLDAP, and that's probably now available anywhere.
13 years, 10 months
