Replication Supplier DN permission denied
by DuWayne Holsbeck
I can not seem to get a read-only replica setup, I have tried every setup
for setting up the supplier DN, but I always get
NSMMReplicationPlugin conn=6 op=11 replica="my dn"Unable to acquire replica:
error: permission denied
any pointers would be greatly appreciated.
Version 1.3.1.9-0ubuntu2
Supplier DN
dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:: XXXXXXXXXXX
passwordExpirationTime: 20380119031407Z
Am I missing attributes, or permisions?
Cheers
DuWayne
9 years, 10 months
Replication between different admin servers
by Chris Taylor
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:1.2.11.15 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.
Thanks,
Chris
9 years, 10 months
Schema for sss_ssh_authorizedkeys
by Trey Dockendorf
I'm attempting to manage user ssh authorized keys in 389 with clients using
SSSD. I came across the RHEL docs [1] 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.
Thanks,
- Trey
[1]
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Lin...
9 years, 10 months
Re: [389-users] Fwd: dirsrv gosa to 389 questions on some capabilities
by Noriko Hosoi
Hi Zynda,
> 1. The ability to restrict users to specific hosts, adding hosts list.
We have Access Control to restrict the IP address / hosts accessing the
server from.
13.4.6. Defining Access from a Specific IP Address
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Serv...
13.4.7. Defining Access from a Specific Domain
https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Serv...
> 2. The ability to restrict users to specific sudo commands.
This is beyond the 389-ds-base directory server, but our higher layer
product FreeIPA (http://www.freeipa.org/page/Main_Page) has the ability.
http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/defining...
> 3. Tying in svn or git with changes.
Could you give us more details what you are looking for?
We have this git page, on which you could see the tags corresponding to
the release.
https://git.fedorahosted.org/cgit/389/ds.git/
For instance, the latest el6:
http://directory.fedoraproject.org/wiki/Releases/1.2.11.29
Tag: 389-ds-base-1.2.11.29
<https://git.fedorahosted.org/cgit/389/ds.git/tag/?id=389-ds-base-1.2.11.29>
(https://git.fedorahosted.org/cgit/389/ds.git/tag/?id=389-ds-base-1.2.11.29)
Thanks,
--noriko
Zynda, Bradley V. (GSFC-423.0)[ADNET SYSTEMS INC] wrote:
> Hi Noriko,
>
> Would you happen to have any suggestions or ideas as to the (1-3) I have
> listed below?
>
> Would 1 and 2 be doable from the admin GUI?
>
> Thank you for your time,
> Brad
>
>
> -------- Original Message --------
> Subject: [389-users] dirsrv gosa to 389 questions on some capabilities
> Date: Mon, 19 May 2014 16:51:46 +0000
> From: Zynda, Bradley V. (GSFC-423.0)[ADNET SYSTEMS INC]
> <bradley.v.zynda(a)nasa.gov>
> Reply-To: General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>
> To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org>
>
> Hi All,
>
> 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.
>
>
> Thanks,
> Brad
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
9 years, 10 months
Yum Update vs Yum Upgrade
by Fong, Trevor
Hi Everyone,
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 1.2.11.15-14.el6_4 --> 1.2.11.29-1.el6
Thanks,
Trev
---------------------------------------------------------
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
9 years, 10 months
db2ldif vs ldapmodify: turn up debugging of db2ldif?
by Morgan Jones
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.
thanks,
-morgan
[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
<paste entry>
adding new entry "uid=xxxx,ou=students,dc=domain,dc=org"
9 years, 10 months
Group Member Sync 389 to AD
by DuWayne Holsbeck
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
greatly appreciated.
Cheers
DuWayne
9 years, 10 months
Account Lockout Policies
by Dustin Rice
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.
Thanks!
--
=====================================
Dustin Rice
UNIX System Administrator - CIS
Portland State University
=====================================
9 years, 10 months
Sort control: can I sort by an attribute without a schema (using extensibleObject)
by Graham Leggett
Hi all,
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
Regards,
Graham
--
9 years, 10 months