389-users September 2006

389-users@lists.fedoraproject.org

42 participants
58 discussions

[Fedora-directory-users] SSHA Password hash function
by Radek Hladik 10 Sep '06

10 Sep '06

Hi all, I'm trying to get working SSHA password generation in JavaScript. I've found interesting topic which I want to ask about. Is there any presumption about salt length? I've tried salt "saltedsalt" and password "abcd". It produced string {SSHA}/OwjNeakcceT6szrxGOMHUb53XJzYWx0ZWRzYWx0 which when inserted into userPassword attribute crashed slapd daemon when the user tried to log on. With random salt of length 13 everything works fine. Maybe there is some mistake related to base64 padding, but even with one or two trailing = this hash crashed the slapd daemon. FDS is 1.0.2 Radek

2 2

[Fedora-directory-users] HOWTO: put a pair of SSL-enabled servers behind a VIP (or a few VIPS)
by Philip Kime 09 Sep '06

09 Sep '06

I just did this and thought others might like to see the procedure if the non-VIPed setup is already running. The issue is the SSL certs - they won't like the names/IPs of the VIPs and will complain (or depending on your setup, fail completely) when starting SSL/TLS. I assume your VIPs exist - here's how to change the SSL certs to work with the VIPs You already have the two servers up and running on SSL with their certificates working. How do you change the certificates to include the VIP names so things like "ldapsearch -ZZZ" don't die? You have to add an X.509 v3 "SubjectAltName" certificate extension to the certificate. But you can't add it, so you have to create a new certificate. This is how I did it and it has minimal impact - just one quick FDS restart (and even that might not be strictly necessary - please correct me). My situation was having two ldap servers and needing to put them behind two load-balanced VIPs. ldap1.foo.com ldap2.foo.com For each server, I did this: Generate a certificate request from the server. Either in the GUI and paste to a file or go into /opt/fedora-ds/alias and do /opt/fedora-ds/shared/bin/certutil -R -d /opt/fedora-ds/alias -s <SUBJECTNAME> -o cert.req -a You may need the "-P" flag if your cert8.db and key3.db files for the DS are not the default names. I tend to use "-a" for ascii output as I have had problems with binary requests and certs in the past. Where "<SUBJECTNAME>" is the DN for the Certificate. This is the nice part - make sure that this is *exactly* the same as your already-in-use SSL cert's Subject DN. To find this out what this is, do /opt/fedora-ds/shared/bin/certutil -L -n <CERTNAME> -d /opt/fedora-ds/alias Again, you may need the "-P" flag if your cert db files are not the default names. Here "<CERTNAME>" is the name of your server SSL cert. You can list all the cert names with: /opt/fedora-ds/shared/bin/certutil -L -d /opt/fedora-ds/alias If you are generating the cert request in the GUI, you can either enter the DN information in the seperate fields or choose the DN view and just past it in. Generate the request, get it into a file called "cert.req" and do this /opt/fedora-ds/shared/bin/certutil -C -d /opt/fedora-ds/alias -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 <VIPs> This is where you generate the cert with the extensions. <CACERT> is the name of your CA cert that is issuing the certificate - make sure it's the same CAcert that issued your current SSL cert (that way your clients which have the existing public CAcert wont' break). You can find out the name of it in the same way as described above for the server cert name. <ID> is a unique, arbitrary serial number for the cert. The only restriction is that it should definitely not be the same serial number as your existing cert(and not the same as any other certs you use either, really). <VIPs> - this is a comma-separated list of DNS names (can be IP addresses) of your VIPs. Basically, this option says "these names are valid matches for the hostname of the server too". "-v" sets the expiration on the certificate in months. Set it to whatever you want. You'll be prompted for the internal token to access the certificate database - I tend to use the "-f file" flag to get this from a file where it's stored. In our example: /opt/fedora-ds/shared/bin/certutil -C -d /opt/fedora-ds/alias -c <CACERT> -i cert.req -o cert.crt -a -m <ID> -v 120 -8 ldap1.foo.com,ldap2.foo.com The resulting certificate is left in the "cert.crt" file. Then install the certificate in the GUI (copy-paste is easy) - it will tell you that the Subject DN is identical to the certificate already installed and so it will call it by the same name. This is good and by design. So, now you will see two certificates with the same name. Delete the older one without the extensions (easy to do this in the GUI). I restarted the DS at this point in case it had cached the old certificate but this may not be necessary. That's it. Your certificate now has the extensions to allow it to work with the VIP names and TLS/SSL won't complain. ldapsearch -ZZZ should still work fine. You can check the certificates by the "certutil -L" commands above and you should see this in the certificate: Signed Extensions: Name: Certificate Subject Alt Name DNS name: "ldap1.foo.com" DNS name: "ldap2.foo.com" The trick with keeping the Subject DN the same (but changing the serial number, which is mandatory), means that you don't have to go into the DS setup and change the certificate name being used ... it just carries on working with minimal impact. -- Philip Kime NOPS Systems Architect 310 401 0407

1 0

[Fedora-directory-users] SASL authentication
by Josh Kelley 08 Sep '06

08 Sep '06

SASL authentication appears to be operating incorrectly on my install of FDS. We do not use SASL; our passwords are stored in FDS using CRYPT-MD5, SMD5, and SSHA256, depending on when and how the account's password was last changed. As I understand it, SASL authentication using DIGEST-MD5 and CRAM-MD5 only works if passwords are stored in cleartext in FDS. Is this correct? The problem is that our OS X clients, when configured for LDAP authentication, try a SASL bind (CRAM-MD5) first then fall back to a simple bind if that fails. When OS X checks a login against an OpenLDAP server, the server returns resultCode 80 (other), error message "SASL(-13): user not found: no secret in database", and so the client falls back to a simple bind. However, when OS X tries a SASL bind against FDS, the server returns resultCode 49 (invalidCredentials), error message "SASL(-13): authentication failure: incorrect digest response", and so the client assumes that the login failed. Is this a bug in FDS? Or did I misconfigure something? Is there an easy workaround? Our Macs are mostly unusable until I can get this fixed. Thanks. Josh Kelley

3 7

[Fedora-directory-users] ds gateway behind apache proxy
by Mikael Kermorgant 08 Sep '06

08 Sep '06

Hello, I have installed FDS and activated dsgw which listens on a particular port, let's say 29154. I have managed to access it on port 80 by running apache2 on the same host and setting up mod_proxy in a particular way but it does only work for some pages. RewriteRule ^/clients(.*) /directory/clients$1 [R] <Location /annuaire/> ProxyPass http://ds.myorg.com:29154/ ProxyPassReverse http://ds.myorg.com:29154/ </Location> My problem is that there are hard-coded references to this port in the html files. For an example, after authentication, I have : <INPUT TYPE="button" VALUE="Return to Main" onClick="top.location.href=\'http://ds.myorg.com:29154/clients/dsgw/bin/lang?context=dsgw&file=\'"> Is there a way to configure this ? Thanks in advance, -- Mikael Kermorgant

2 2

[Fedora-directory-users] ds_newinst.pl
by Diana Shepard 07 Sep '06

07 Sep '06

I have Fedora Directory Server 1.0.2 installed on Redhat Linux. I am trying to come up with a Disaster Recovery kickstart install of the server, Directory Server (DS) and DS contents. I tried ds_newinst.pl, as described in the Fedora DS Install Guide, to create a new DS instance from the command line, using the following ".inf" file: [General] FullMachineName= drtest.cusys.edu SuiteSpotUserID= ldap ServerRoot= /opt/fedora-ds [slapd] ServerPort= 40003 ServerIdentifier= sisauth Suffix= dc=cusys,dc=edu RootDN= cn=Directory Manager RootDNPwd= xxxxxxxx It executed successfully, created the expected directory structure, the DS is listening on the correct port, but when I go to the Console, the 2nd "sisauth" instance, the first being "config" isn't there. How can that be? Diana Shepard University of Colorado

2 1

[Fedora-directory-users] scheduled backup
by basile 07 Sep '06

07 Sep '06

hi is it possible to scheduled backup through fedora console thanks basile

2 3

[Fedora-directory-users] install/uninstall admin-serv
by Diana Shepard 06 Sep '06

06 Sep '06

The problem is that whenever I try to start the Directory Server Console via command line "startconsole", I get the following error (libjss3.so is in /opt/fedora-ds/lib, and readable): Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/fedora-ds/lib/libjss3.so: /opt/fedora-ds/lib/libjss3.so: cannot open shared object file: No such file or directory at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1485) at java.lang.Runtime.loadLibrary0(Runtime.java:788) at java.lang.System.loadLibrary(System.java:834) at org.mozilla.jss.CryptoManager.loadNativeLibraries(CryptoManager.java:133 0) at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:822) at org.mozilla.jss.CryptoManager.initialize(CryptoManager.java:795) at com.netscape.management.client.util.UtilConsoleGlobals.initJSS(Unknown Source) at com.netscape.management.client.util.UtilConsoleGlobals.getLDAPSSLSocketF actory(Unknown Source) at com.netscape.management.client.console.Console.LDAPinitialization(Unknow n Source) at com.netscape.management.client.console.Console.<init>(Unknown Source) at com.netscape.management.client.console.Console.main(Unknown Source) Diana Shepard Date: Mon, 28 Aug 2006 15:59:40 -0600 From: Richard Megginson <rmeggins(a)redhat.com> Subject: Re: [Fedora-directory-users] install/uninstall admin-serv only To: "General discussion list for the Fedora Directory server project." <fedora-directory-users(a)redhat.com> Message-ID: <44F3674C.1090202(a)redhat.com> Content-Type: text/plain; charset="iso-8859-1" Diana Shepard wrote: > > Is there a way to unistall and reinstall the > admin-serv only? > Maybe, it depends. > > Mine seems to have gotten corrupted > somehow. > What seems to be the problem? > > Diana Shepard > University of Colorado >

3 11

[Fedora-directory-users] Re: LD_LIBRARY_PATH question - SOLVED
by Philip Kime 06 Sep '06

06 Sep '06

Groan. I have solved the problem. It was a combination of things. I didn't realise that FDS would do SSL console connections in X out of the box. There is no need to get any other bits of Java and libs. The version of JSS that comes with 1.0.2 is 3.7, which is fine. Once I'd fixed that and reverted to the out of the box JSS .jar and lib, the error was ./startconsole -a https://ldapserver:38900/ Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/fedora-ds/lib/li bjss3.so: /opt/fedora-ds/lib/libjss3.so: cannot open shared object file: No such file or directory This is typically because you are using a 32-bit Java and trying to load a 64-bit library. As RM has said on other threads, just run "file" on the lib and on the java binary and if the Java is 32-bit but the library is 64-bit, that's the problem. That was exactly my problem. I downloaded Java originally without scrolling a little bit further down to find the x64 JDK ... when I swapped Java to a 64-bit version, it all worked fine. Many thanks for the help, even though I was just being stupid ... PK

1 0

[Fedora-directory-users] Re: LD_LIBRARY_PATH question
by Philip Kime 06 Sep '06

06 Sep '06

> Weird. I just installed that rpm on a rhel4 x86_64 system and I got > totally different numbers from what you reported in your earlier email, > quoted below: Sorry, me being stupid. I had followed the instructions here: http://directory.fedora.redhat.com/wiki/Howto:WindowsConsole For getting the console up with SSL but had looked on the ftp server the for the relevant Linux libs. Turns out that the jss3.3 on there is older than the included one. Once I grabbed the original again, the LD_LIBRARY_PATH worked. However, when I put the right libjss3.so in, I can't start the console in X any more: ./startconsole -a https://ldapserver:38900/ Exception in thread "main" java.lang.UnsatisfiedLinkError: /opt/fedora-ds/lib/li bjss3.so: /opt/fedora-ds/lib/libjss3.so: cannot open shared object file: No such file or directory It can't load itself? Ldd output looks fine now. So now my question is - which version is the libjss3 that comes with 1.0.2? And if I need to get X consoles working over SSL again, what version of the jss jar do I need? I seem to have a choice between a broken libjss3 which makes X consoles work and the right one, which doesn't ...

2 1

[Fedora-directory-users] Chain on Update Problem
by James B Newby 06 Sep '06

06 Sep '06

Hello all, I'm having a problem with my consumer's chain on update. I have a setup with two masters and one consumer. Multi-master replication is working properly. Changes made on either master propagate to the other master and to the consumer. Before setting up chaining, changes made on the consumer from the directory console would be denied. After setting up chaining per the wiki entry: http://directory.fedora.redhat.com/wiki/Howto:ChainOnUpdate , changes could be made on the consumer through the directory console, but would not propagate to the master. I saw an e-mail with a similar problem in the December 2005 archive, but didn't see any info in the replies that would help me. I've tried setting this up from scratch a couple times, but without success. The responses to ILoveJython's email in December suggested that certain entries be pasted in, so I've included them below. The following acl is included in dc=hg,dc=com: (targetattr = "*")(version 3.0; acl "Proxied authorization for database links";allow (proxy) (userdn = "ldap:///cn=Replication Manager, cn=config");) Since multi-master replication is set up, this entry is present on all three servers. Any help would be appreciated! Thanks! -James dn: cn="dc=hg,dc=com",cn=mapping tree, cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree nsslapd-state: backend cn: "dc=hg,dc=com" cn: dc=hg,dc=com nsslapd-backend: userRoot nsslapd-backend: chainbe1 nsslapd-referral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com nsslapd-referral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com nsslapd-distribution-plugin: /opt/fedora-ds/lib/replication-plugin.so nsslapd-distribution-funct: repl_chain_on_update dn: cn=replica,cn="dc=hg,dc=com",cn=mapping tree, cn=config objectClass: nsDS5Replica objectClass: top nsDS5ReplicaRoot: dc=hg,dc=com nsDS5ReplicaType: 2 nsDS5Flags: 0 nsds5ReplicaPurgeDelay: 604800 nsDS5ReplicaBindDN: cn=Replication Manager,cn=config cn: replica nsDS5ReplicaId: 65535 nsState:: //8AAIcx9kQAAAAAAAAAAAEAAAA= nsDS5ReplicaName: ddc65803-1dd111b2-80e6a7e3-5afe0000 nsDS5ReplicaReferral: ldap://ldap1.mw1.highergear.com:1389/dc=hg,dc=com nsDS5ReplicaReferral: ldap://ldap2.mw1.highergear.com:1389/dc=hg,dc=com nsds5ReplicaChangeCount: 0 nsds5replicareapactive: 0 dn: cn=config,cn=chaining database,cn=plugins,cn=config cn: config objectClass: top objectClass: extensibleObject nstransmittedcontrols: 2.16.840.1.113730.3.4.2 nstransmittedcontrols: 2.16.840.1.113730.3.4.9 nstransmittedcontrols: 1.2.840.113556.1.4.473 nstransmittedcontrols: 1.3.6.1.4.1.1466.29539.12 nspossiblechainingcomponents: cn=resource limits,cn=components,cn=config nspossiblechainingcomponents: cn=certificate-based authentication,cn=component s,cn=config nspossiblechainingcomponents: cn=ACL Plugin,cn=plugins,cn=config nspossiblechainingcomponents: cn=old plugin,cn=plugins,cn=config nspossiblechainingcomponents: cn=referential integrity postoperation,cn=plugin s,cn=config nspossiblechainingcomponents: cn=attribute uniqueness,cn=plugins,cn=config dn: cn=chainbe1, cn=chaining database, cn=plugins, cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: chainbe1 nsslapd-suffix: dc=hg,dc=com nsfarmserverurl: ldap://ldap1.mw1.highergear.com:1389 ldap2.mw1.highergear.com :1389/ nsmultiplexorbinddn: cn=Replication Manager, cn=config nsmultiplexorcredentials: {DES}<PASSWORD ERASED> nsbindconnectionslimit: 3 nsoperationconnectionslimit: 20 nsabandonedsearchcheckinterval: 1 nsconcurrentbindlimit: 10 nsconcurrentoperationslimit: 2 nsproxiedauthorization: on nsconnectionlife: 0 nsbindtimeout: 15 nsreferralonscopedsearch: off nschecklocalaci: on nsbindretrylimit: 3 nsslapd-sizelimit: 2000 nsslapd-timelimit: 3600 nshoplimit: 10 nsmaxresponsedelay: 60 nsmaxtestresponsedelay: 15

3 12

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users September 2006