How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
CentOS release 6.3 (Final)
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
06/04/2013 12:39 PM, Denise Cosso wrote:
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
389 users mailing list
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
I'm attempting to import an LDAP schema (is that the correct term?) from
one LDAP implementation to another and it appears that I may be doing it
incorrectly. I created a ldif file for import as:
ldapsearch -b "o=companyA" -D "dc=hq,dc=example,dc=com" -h original_system
I then used the GUI in the new LDAP implementation to import the ldif file.
Everything seemed to work find as I have the entire tree but there appears
to be a problem with passwords.
Am I missing the passwords for users with this export to ldif file? What
is the proper procedure to import all information from a schema (is that
the correct term?) to import into a new LDAP implementation?
Thanks in advance for any assistance,
I've added the inetUser object class to the nsdefaultobjectclass the the
However when I add a new user the user does not have inetUser object
class. Any idea?
# extended LDIF
# base <o=netscaperoot> with scope subtree
# filter: cn=user
# requesting: ALL
# user + inetorgperson, defaultObjectClassesContainer, 1.1, Admin,
ferences, example.local, NetscapeRoot
# search result
result: 0 Success
# numResponses: 2
# numEntries: 1
Surely we can't be the only ones who want to this?
From: Fong, Trevor
Sent: April-22-14 3:33 PM
Subject: Sync from RDBMS to LDAP
We are in the process of migrating from an old OpenLDAP service to 389-DS.
We currently synchronise users and attributes from an Oracle DB to OpenLDAP service using an aging set of custom scripts and DB triggers.
We would like to do something similar for 389-DS but using a commercial-off-the-shelf solution.
I was wondering what the good people on this list use or would recommend?
Thanks in advance,
Trevor Fong - Senior Programmer Analyst
Identity and Access Management Group
University of British Columbia - Information Technology
6356 Agricultural Road, Vancouver, BC, V6T 1Z2, Canada
Ph: (604) 827-5247
I'm a new user about 389 DS. I installed it on a RHEL 6 (32bit) server:
I've troubles with groups. I created posix user and group. I'm able to
login on the Linux client (SL 6 32bit) but I receive the error: cannot
find name for group ID.
I had search on google to find a solution, but all the suggestions I've
find didn't work for me.
This is the sssd.conf on the client, with all attempts to solve the
ldap_schema = rfc2307bis
ldap_id_use_start_tls = True
cache_credentials = True
ldap_search_base = dc=mydomain,dc=it
#krb5_realm = EXAMPLE.COM
#krb5_server = kerberos.example.com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldaps://myserver
ldap_tls_cacertdir = /etc/openldap/cacerts
entry_cache_timeout = 600
ldap_network_timeout = 3
#ldap_group_name = uniqueMember
ldap_group_object_class = groupofuniquenames
services = nss, pam
config_file_version = 2
domains = default
If I add the member to the group through the management console
group->Members->Static Group, switch on the ldap_group_name =
uniqueMember parameter on the client, clear cache, restart sssd and
type id user I obtain:
There is a way to solve the problem?
System Administrator | Programmer | Web Developer
CERM - Polo Scientifico
Via Sacconi, 6 - 50019 Sesto Fiorentino (FI) - ITALY
phone: +39 055 457 4269
fax: +39 055 457 4927
I’m trying to import an openldap-2.3.27 export into 389-ds-1.2.2-1 and am
getting the follow errors in the “rejects” file:
Invalid syntax. cn: value #0 invalid per syntax
Sample: cn:: TWFyaW8gUmH6bCBDaGFuZw==
I’ve determined (I think) that these errors are from CN value pair that are
base64 encoded LATIN1 characters. If I decode string(base64 command),
convert it to UTF8(via iconv), I can import into Fedora389 successfully. I
have a lot of entries with these values and am looking for an easy solution.
Has anyone come across this before and written a script to process an LDIF
file or a different way to transfer the data? I’m not much of a programmer
but I do have programmers in my organization that could assist me if a
script is the best solution.
I'd like to try out the web interface, and I'm trying to follow along with
some tips I've found online. I have dsgw installed on my server
(389-dsgw-1.1.11-1.el6.x86_64). I ran the setup-ds-dsgw script and
restarted the admin server, but going to http:<my_ip>:9830 just times out.
If I copy /etc/dirsrv/dsgw/dsgw-httpd.conf to my server's apache
directory, restart apache, and try going to http://<my_ip>/dsgw, I get an
error stating "Problem Bad or missing configuration file (Cannot open
That file is there, so what do I have to do to make this work? Do I have
to edit the dsgw-httpd.conf and configure that further?
Thanks for any tips!
Common ARTS Software Development
I have all kinds of borkage in my ldap today.
I created a new ou in one of my data centers,
under this I added 2 users. About 5 minutes later I got an alarm from my
monitoring system saying that replication had failed, and I discovered
that replication from this data center to my second data center had
failed, and more specifically this ou --
[22/Apr/2014:15:28:03 -0500] - Retry count exceeded in add
[22/Apr/2014:15:28:03 -0500] NSMMReplicationPlugin - conn=437731 op=4
csn=5356cc22000000010000: Can't created glue entry ou=CDC,ou=Service
uniqueid=dde5bb01-ca5811e3-af3cad6b-9c050417, error 51
So I thought there was something wrong in the new ou I'd created so I went
back and deleted the two children, then tried to delete the ou. But my
ldap thinks that the children still exist and won't let me delete the ou
[22/Apr/2014:15:45:17 -0500] entryrdn-index - _entryrdn_delete_key: Failed
to remove ou=cdc; has children
[22/Apr/2014:15:45:17 -0500] - database index operation failed BAD 1031,
err=-1 Unknown error: -1
Any thoughts on how to proceed with this? I'm afraid to do anything else
on the first server now that I've managed to get it into this state.