I am having problems disabling the RC4 ciphers on the admin server. There are 3 tabs in the GUI separating SSL2, SSL3 and TLS. The TLS tab has 4 options, 2 of which involve RC4 ciphers. The GUI allows me to un-select the RC4 buttons and save. It presents a notice that the admin server needs to be restarted. After closing the GUI, I restart the admin server and log back into the GUI. Checking the ciphers on the admin server, the RC4 ciphers are enabled on the TLS tab.
In the console.conf for the admin server, NSSCipherSuite lists the SSL3 ciphers but I do not see any of the TLS ciphers listed in table 7.3 of the RH Dir. Serv. Admin guide (p312).
To disable these ciphers can I just add "-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_r4_sha,-tlsdhe_dss_rc4_128_sha" to the NSSCipherSuite variable?
Jean Redfearn, CISSP, RHCE, GCIH
I have two new RH7 servers each running 389ds and each with a test ldap instance and a test master.
I set up replication from our old ldap servers (iPlanet 5 on Solaris) to these new instances so they keep up to date with everything until we are ready to switch the VIPs to point to these new ones both both updates to the masters and queries to the ldap instances.
Everything was working fine until I set up replication between the config directories on these new servers (not sure if that was the cause, but timing is that the issue occurred just after this). When I went to restart one of the query directorsies it failed with this logged:
dse_read_one_file - The entry cn=schema in file /etc/dirsrv/slapd-ldaptest1/schema/99user.ldif (lineno: 1) is invalid, error code 20 (Type or value exists) -
I thought it might have been caused by the replication of config. So, I blew away one of the directory instances then rebuilt it and configured consumer replication again. From the primary supplier I re-initialized it which succeeded. But, when I tried a restart it failed again with the same error. The time stamp on 99user.ldif was the same as when the total update started.
Any suggestions how I can find out what is getting messed up in the schema? Do I need to turn up more logging to try to get info more than what the unhelpful message above tells me?
Ted F. Fisher
Information Technology Services
I am having some unexpected behaviour from 389ds v18.104.22.168-32 on CentOS7 and I need to check if this looks familiar to anybody.
After installing 389ds and configuring it successfully, and proving successfully that I can connect to it and that it contains data, I restarted the machine to prove the server comes up on reboot. 389ds refused to come up.
Attempts to bring the server up manually using “systemctl start dirsrv.target” have no effect.
What eventually got the service to start was “systemctl restart dirsrv@instancename”, but this hasn’t solved the start-at-boot problem.
Does anyone have an accurate guide on 389ds and systemd?
We would like to connect our services to 389DS. Each user would have an
attribute that would determine their quota for each service.
We have a registered space within the OID tree for our organization and
the attributes would go there.
For for the quota attribute I was thinking multivalue. Something like
(numbers and names are arbitrary):
The service would request the attribute and then parse out its own
value. All nice and good for our in-house apps.
There is a problem, when a service like dovecot expects the value to be
a number. Then, as we tested, the multivalue idea does not work.
Is there a way to use the filters so a query returns only the number
(500 from mail:500)?
Could it be done with 389DS plugins?
ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
tel: +386 1 479 8800, fax: +386 1 479 88 99
Hello everyone, this is my first post. I am looking for an alternative to migrate from Active Directory. I would like to know if it is possible the "human" integration between samba4 and 389-DS.
Is there a way to export users including the userPassword hashed and then reimporting again ?
I tried but I keep getting the following:
#!ERROR [LDAP: error code 19 - pre-hashed passwords are not valid ]
I am able to change nsaccountlock value using 389ds client software by right clicking on users and selecting active or inactive. but I need to change nsaccountlock value using an ldif file. The content of the file is :
but unfortunately the value doesn't change. the ldapmodify command returns no error and there is no error in logs either.
I appreciate any help on this subject.