I currently have two instances of LDAP setup the first is a set of CentOS-DS servers in an MMR setup running version Version: 8.2.8 Build Number: 2012.041.1227. I am trying to transition to an new setup that will be running Version:184.108.40.206 Build number:2014.072.1937.
My question is that since these running different versions on different admin servers is it possible to setup replication between the two? Or would it just be best to do an export/import of the data and cut over to the new systems?
Any guidance would be appreciated.
I'm attempting to manage user ssh authorized keys in 389 with clients using
SSSD. I came across the RHEL docs  regarding the sss_ssh_authorizedkeys
application but I do not see mention of the expected attributes for a user
account to use this method. Does 389 include the necessary schema? If
so, what attributes should I look into? If the schema does not exist, is
there a place I can reference to see how FreeIPA implements the schema to
then add as a custom schema to my 389 instance?
I realize FreeIPA contains this functionality but I can not use FreeIPA
because our authentication is provided by our campus' Kerberos realm and we
use 389 PAM pass through plugin to authenticate users. As far as I'm aware
this functionality cannot be used in FreeIPA without OTP which is not
available in EL6 or EL7.
After taking over the LDAP service from a colleague, I updated the 389 DS service to the latest release by issuing a "yum update ...". Then when searching around the 389-ds documentation, I came across the install page that said that I must use "yum upgrade ..." and not update.
My question is what's the difference between yum update and upgrade? Is it OK if I leave it like that or should I do the yum upgrade? The service seems to be running OK after "yum update", so far.
I went from 220.127.116.11-14.el6_4 --> 18.104.22.168-1.el6
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 am working on a move from CentOS Directory (8.2.8) on CentOS 5 to 389-ds 1.2.11 on CentOS 6. I’m using a combination of the CentOS repositories and epel as suggested here.
I'm finding ldif2db rejects entries while if I add them via ldapmodify they go in with no errors. This is a problem as db2ldif does not give sufficient debugging to identify the problem. Below are examples. Is there a way to get more debugging out of ldif2db that I am missing? Perhaps an error log level I’m missing? Has anyone else seen this behavior?
I'm importing into a database other than userRoot if that makes a difference.
[root@devldapm03 ~]# /usr/lib64/dirsrv/slapd-devldapm03/ldif2db -n studentRoot -i /var/tmp/students_fixed.ldif
importing data ...
[19/May/2014:15:53:48 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[19/May/2014:15:53:48 -0400] - check_and_set_import_cache: pagesize: 4096, pages: 2015405, procpages: 52243
[19/May/2014:15:53:48 -0400] - Import allocates 3224648KB import cache.
[19/May/2014:15:53:49 -0400] - import studentRoot: Beginning import job...
[19/May/2014:15:53:49 -0400] - import studentRoot: Index buffering enabled with bucket size 100
[19/May/2014:15:53:49 -0400] - import studentRoot: Processing file "/var/tmp/students_fixed.ldif"
[19/May/2014:15:55:04 -0400] - import studentRoot: WARNING: skipping entry "uid=xxxx,ou=students,dc=domain,dc=org" which violates attribute syntax, ending line 5457262 of file "/var/tmp/students_fixed.ldif"
# ldapmodify -x -a -h devldapm03.domain.net -D cn=directory\ manager -w pass
adding new entry "uid=xxxx,ou=students,dc=domain,dc=org"
I have a 389 and AD servers setup, and sync agreements configured for
users, and groups. The Groups synced fine, but on the AD side there are
no members in the groups. I set the ntGroup objectClass, ntGroupType,
ntGroupCreateNewAccount, ntGroupDeleteAccount, ntUniqueId attributes set
on the 389DS side.Initial sync runs without errors.
Am I missing something, or is there a trick to get the Group memberships
to sync up between the 2?
Any suggestions on a fix, or way to troubleshoot the issue would be
Hello there, so I've been looking into setting up some account lockout
policies in my enviroment. I have 2 multimaster 389ds servers with some
389ds consumer replicas. I've enable passwordIsGlobalPolicy in cn=config
on all servers.
So if an account gets locked out when binding to a master, it is indeed
locked out from the replicas. This functionality doesn't seem to flow in
the opposite direction. If I get locked out on replica1, I can happily
bind to replica2.
Since replication flows "down" from master to consumer, I don't think
there is a way to get the lockout information passed "up" to the
masters then back "down" to peer consumers, but figured I'd ask the list.
So, is there a way to pass account lockout information from consumer
replicas back to masters? The end goal here is that if an account is
locked out for too many failed attempts it is globally locked out.
UNIX System Administrator - CIS
Portland State University
I am currently trying to add a sort control to an LDAP query, but the attribute I am trying to sort on isn't defined in the schema - the attribute exists as the object has extensibleObject.
I am getting a NamingException from our code, and the 389s log reports error 12 as below. Is what I'm trying to do possible?
[20/May/2014:16:39:09 +0000] conn=70187 op=3 SORT status (52)
[20/May/2014:16:39:09 +0000] conn=70187 op=3 RESULT err=12 tag=101 nentries=0 etime=0 notes=U
by Zynda, Bradley V. (GSFC-423.0)[ADNET SYSTEMS INC]
We are currently in the process of moving to a fresh Cent6.5 389
setup. The old setup was an improperly configured Gosa dirsrv and we
would like to get away from gosa on the new 389 build. Though I have
come across some needs that I can't seem to find documentation on:
1. The ability to restrict users to specific hosts, adding hosts list.
2. The ability to restrict users to specific sudo commands.
3. Tying in svn or git with changes.