[Fedora-directory-users] SSHA Password hash function
by Radek Hladik
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
17 years, 7 months
[Fedora-directory-users] HOWTO: put a pair of SSL-enabled servers behind a VIP (or a few VIPS)
by Philip Kime
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
17 years, 7 months
[Fedora-directory-users] SASL authentication
by Josh Kelley
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
17 years, 7 months
[Fedora-directory-users] ds_newinst.pl
by Diana Shepard
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
17 years, 7 months
[Fedora-directory-users] install/uninstall admin-serv
by Diana Shepard
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
>
17 years, 7 months
[Fedora-directory-users] Re: LD_LIBRARY_PATH question - SOLVED
by Philip Kime
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
17 years, 7 months
[Fedora-directory-users] Re: LD_LIBRARY_PATH question
by Philip Kime
> 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 ...
17 years, 7 months
[Fedora-directory-users] Chain on Update Problem
by James B Newby
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
17 years, 7 months
