How to convert Solaris m5 passwords to LDAP?
Hi all, we want to switch a server machine from Solaris (credentials stored in traditional passwd and shadow file) to Debian with OpenLDAP for authentication. Creating LDIF files from /etc/passwd and /etc/shadow using PADL's migrationtools is working fine. The only problem is, that many user passwords on the Solaris machine have been encrypted using Sun's md5 scheme which results in hashes beginning with the characters $md5$. These hashes can be imported into our LDAP directory, but they cannot be used for authentication: Each attempt results in access denied on the client side and LDAP bind errors on the server side. Even when adding the user information to /etc/passwd and /etc/shadow on the Linux machine, there's no success. With CRYPT password hashes, everything works fine. Do you know any means to convert these Solaris-md5-hashed password strings into something we can use with OpenLDAP? I appreciate your helpful answers. Thanks in advance! Gruss/Regards, Christian Schmidt -- You have an ability to sense and know higher truth.
Re: How to convert Solaris m5 passwords to LDAP?
Christian Schmidt wrote:
Hi all,
we want to switch a server machine from Solaris (credentials stored
in traditional passwd and shadow file) to Debian with OpenLDAP for
authentication.
Creating LDIF files from /etc/passwd and /etc/shadow using PADL's
migrationtools is working fine. The only problem is, that many user
passwords on the Solaris machine have been encrypted using Sun's md5 scheme
which results in hashes beginning with the characters $md5$.
These hashes can be imported into our LDAP directory, but
they cannot be used for authentication: Each attempt results in
access denied on the client side and LDAP bind errors on the server
side. Even when adding the user information to /etc/passwd and
/etc/shadow on the Linux machine, there's no success.
With CRYPT password hashes, everything works fine.
Do you know any means to convert these Solaris-md5-hashed
password strings into something we can use with OpenLDAP?
I appreciate your helpful answers. Thanks in advance!
No conversion is necessary, as long as you built OpenLDAP with --enable-crypt
and you're using the native C library's crypt() (and not e.g. OpenSSL's
crypt()) and the password is stored with the {crypt} tag. (And the slapd is
actually running on Solaris.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: tls
On Wed, 10 Nov 2010, Christian Bösch wrote: On Nov 10, 2010, at 3:50 , Howard Chu wrote: Christian Bösch wrote: Hi Can someone tell me if it's possible to require strong encryption like TLS except from one IP address? Not exactly. The require directive doesn't have that level of granularity, but you can use ACLs to restrict access. In that case, a user would be able to connect without TLS, but wouldn't be able to access anything. but then user credentials are sent plain i don't want to allow plain simple binds at all except from several ips. if i got you right, this is not possible? Depends on the definition of sent. You can never stop anybody from going out into the street and screaming out their password at the top of their lungs, but you can tell them to quiet down once they do. And you can never stop anybody from forming a packet with their password over the wire, but you can say something like: ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required once they do. If the point is that you want to require TLS, but you have a couple really low-brain devices that don't have the horsepower to encrypt that you still want to access, just reverse the ACL: access to what by peername.ip=1.2.3.4%255.255.255.255 something by peername.ip=1.2.3.5%255.255.255.255 something by ssf=56 something by * none you won't get Confidentiality required (as Howard writes), but you will deny them access should they start putting their password on the wire clear...which hopefully will make a clear hint that they should change their ways.
German Umlauts are converted and also not accepted
Hallo, I'v searched for an answer but did not found one yet. I do have a openldap-2.3.43 server (centos 5.5.) in test and tried to add a ldif-file with my data using the apache directory studio (on mac os x). As my name contains a german umlaut I do get an error adding 'Götz Reinicke' for the gecko. Also for 'displayName', 'cn' and 'givenName' the 'ö' is automatically replaced by 'oe'. If I change the entry in the ldap by hand in the apache DS, the 'ö' is accepted accept for the geckos. An 'ü' in 'o' is manually accepted to. Any hints, explanations, suggestions? Thanks and best regards, Götz -- Götz Reinicke IT-Koordinator Tel. +49 7141 969 420 Fax +49 7141 969 55 420 E-Mail goetz.reini...@filmakademie.de Filmakademie Baden-Württemberg GmbH Akademiehof 10 71638 Ludwigsburg www.filmakademie.de Eintragung Amtsgericht Stuttgart HRB 205016 Vorsitzende des Aufsichtsrats: Prof. Dr. Claudia Hübner Geschäftsführer: Prof. Thomas Schadt smime.p7s Description: S/MIME Cryptographic Signature
Re: pamL-dap configuration guide
Jaap Winius wrote: Quoting Tim Dunphy bluethu...@gmail.com: I was just wondering if anyone happened to know of a good guide to use for configuring centos clients to authenticate pam modules (such as su, sudoers, ssh, system authentication and the like) against openLDAP? I am running a FreeBSD openLDAP server, but I believe that shouldn't affect the clients ability to log in via pam/ldap. Well, I wrote this guide: * PAM configuration guide for Debian http://www.rjsystems.nl/en/2100-pam-debian.php Yes, it's focus is on Debian, but PAM is PAM, so hopefully it will be of some use to you anyway. I second that last comment. PAM configuration should be the same for any system using PAM. When I read the O'Reilly book to learn about setting up PAM/LDAP years ago, I was setting it up on both Linux and IRIX. While many things on IRIX are different, the PAM configuration was identical. That's one of the many great things about PAM. -- Prentice
Re: LDAPCon 2011?
xsun matheus.mor...@gmail.com writes: Hi there, There is something planned to 2011 about an LDAP Conference? I couldn't attend at 2009 and I think is too late for the conference on this year. I haven't planned any, but you may take over and organize a conference. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6
Re: German Umlauts are converted and also not accepted
On Wed, 10 Nov 2010, Christian Manal wrote: Hi, As my name contains a german umlaut I do get an error adding 'Götz Reinicke' for the gecko. Do you mean 'gecos' with that? The 'gecos' attribute from the NIS-schema is an IA5 string [1], which is equal to ASCII. You won't be able to use special characters with that one. Also for 'displayName', 'cn' and 'givenName' the 'ö' is automatically replaced by 'oe'. If I change the entry in the ldap by hand in the apache DS, the 'ö' is accepted accept for the geckos. An 'ü' in 'o' is manually accepted to. How is your ldif file encoded? 'cn', 'givenName' and so on are defined as SUB to 'name', which is defined with Directory Sting syntax [2] aka UTF-8. Regards, Christian Manal When you decide which attribute is to store utf-8 string, look into libnss-ldap manual page to find out how to map other attribute to be used as filling for gecos NSS field. Regards, DT
Re: olcDbURI error
Quoting Pierangelo Masarati masar...@aero.polimi.it: That patch was never committed because the reporter of ITS#6540 said his initial report was not actually relevant for the real issue he was suffering from. Please try that patch and report about its effect; I'll be glad to commit it if it is useful. I'd be happy to do that, but regardless of whether your patch is applied or not, the compile process errors out like this: # ... Entering subdirectory liblber make[3]: Entering directory `/root/openldap-2.4.23/debian/build/libraries/liblber' rm -f version.c /root/openldap-2.4.23/build/mkversion -v 2.4.23 liblber.la version.c /bin/sh ../../libtool --mode=compile cc -Wall -g -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -O2 -I../../include -I/root/openldap-2.4.23/include -DLBER_LIBRARY -c /root/openldap-2.4.23/libraries/liblber/assert.c ../../libtool: line 460: CDPATH: command not found ../../libtool: line 1138: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2.6b Debian-2.2.6b-2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2 libtool: and run autoconf again. make[3]: *** [assert.lo] Error 63 make[3]: Leaving directory `/root/openldap-2.4.23/debian/build/libraries/liblber' make[2]: *** [all-common] Error 1 make[2]: Leaving directory `/root/openldap-2.4.23/debian/build/libraries' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/openldap-2.4.23/debian/build' make: *** [build-stamp] Error 2 r...@ldaps2:~/openldap-2.4.23# _ # A bit of searching gives me the impression that this compile error is not unique to OpenLDAP. I thought of downgrading libtool, but the current version for squeeze hasn't been updated since December 2009. Does anyone have a fix, patch or workaround for this problem? Cheers, Jaap
Re: LDAPCon 2011?
I'm not sure if I can handle this but what do you people think of an LDAPCon 2011 in Brasil? I was talking with some managers here and they are interested in host the conference. So we have place and infrastructure to make the presentations. What do you think about it? On Wed, Nov 10, 2010 at 12:18 PM, Dieter Kluenter die...@dkluenter.dewrote: xsun matheus.mor...@gmail.com writes: Hi there, There is something planned to 2011 about an LDAP Conference? I couldn't attend at 2009 and I think is too late for the conference on this year. I haven't planned any, but you may take over and organize a conference. -Dieter -- Dieter Klünter | Systemberatung sip: 7770...@sipgate.de http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 Thanks, Matheus Morais
number of contextcsn entries per database
I have setup two ldap servers for authentication and access control in a
multi-master configuration. I am concerned about the number of contextcsn
entries that are supposed to be present in each database. Right now there are
two servers participating in the multi-master configuration. From my
understanding, there should be one contextCSN entry per database per host. My
cn=config database has two contextCSN entries as I would expect. One for each
syncrepl rid configured. My bdb database only has one contextCSN entry though,
with an rid of just 000. (my rid's are 001, 002, 101, and 102)
Replication seems to work fine on both databases. I can write to either one and
the changes are replicated over immediately. I am just curious about this
discrepancy in the number of contextCSN entries. Could someone confirm the
number of contextCSN entries per database and if it should match the number of
hosts participating in the multi-master replication? Here are some relevant
settings for the replication:
dn: cn=config
olcServerID: 1 ldap://server1
olcServerID: 2 ldap://server2
###
# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap2.4
olcModuleLoad: {0}syncprov.la
###
# {0}config, config
dn: olcDatabase={0}config,cn=config
olcSyncrepl: {0}rid=001 provider=ldap://server1 binddn=cn=Ma
nager,cn=config bindmethod=simple credentials=password searchbase=cn=config
type=refreshAndPersist retry=5 500 5 + timeout=1 starttls=yes
olcSyncrepl: {1}rid=002 provider=ldap://server2 binddn=cn=Ma
nager,cn=config bindmethod=simple credentials=password searchbase=cn=config
type=refreshAndPersist retry=5 500 5 + timeout=1 starttls=yes
olcMirrorMode: TRUE
###
# {0}syncprov, {0}config, config
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
###
# {1}bdb, config
dn: olcDatabase={1}bdb,cn=config
olcSyncrepl: {0}rid=101 provider=ldap://server1 binddn=cn=Ma
nager,dc=mgcorp,dc=net bindmethod=simple credentials=password searchbase=dc
=mgcorp,dc=net type=refreshAndPersist interval=00:00:00:10 retry=5 500 5 +
timeout=1 starttls=yes
olcSyncrepl: {1}rid=102 provider=ldap://server2 binddn=cn=Ma
nager,dc=mgcorp,dc=net bindmethod=simple credentials=password searchbase=dc
=mgcorp,dc=net type=refreshAndPersist interval=00:00:00:10 retry=5 500 5 +
timeout=1 starttls=yes
olcMirrorMode: TRUE
##
Here are the results of searches for contextCSN in cn=config and
dc=mgcorp,dc=net:
ldapsearch -x -W -s base -D cn=Manager,cn=config -h server2 -b
cn=config contextCSN
contextCSN: 20101110214932.998233Z#00#000#00
contextCSN: 20101028121213.444193Z#00#001#00
ldapsearch -x -W -s base -D cn=Manager,dc=mgcorp,dc=net -h server2 -b
dc=mgcorp,dc=net contextCSN
contextCSN: 20101110213409.736943Z#00#000#00
