Re: [Freeipa-users] diskless workstations in an IPA domain

2016-10-13 Thread Jacquelin Charbonnel 

Thank you for this information. Yes, /tmp is writable.

	My problem is : access are sometimes definitively refused for random 
user who wants to log in diskless workstations.
	But if this banned user tries to connect to the single machine which 
mounts the fs in rw mode, it's work, and this solve immediately its 
problem on all the other stateless machines !? Strange...


Le 13/10/2016 à 20:33, Jakub Hrozek a écrit :

On Thu, Oct 13, 2016 at 05:45:32PM +0200, Jacquelin Charbonnel wrote:

Hi everybody,

What is the best practice to enroll diskless Fedora24 workstations 
(under
stateless Linux) into a IPA domain ?
Each diskless workstation mounts its filesystem in RO mode from a single
NFS share, with some specific directories (like /var/lib/sss) mapped RW in
RAM.


I can't speak for other components, but /var/lib/sss/ is the only
directory sssd writes to (except tmpfiles, but I guess /tmp would also
be a writable fs?)



--
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread Martin Basti 



On 13.10.2016 22:23, John Popowitch wrote:

Ok, so I'm looking at fixing the conflicts for ' System: Modify Certificate 
Profile'.
I ran this on each server:
ldapsearch -Y GSSAPI -b 'dc=aws,dc=cappex,dc=com' "cn=*Modify Certificate 
Profile*" \* nsds5ReplConflict

And now to make things interesting, this query has different results on each 
server.
Server #1:
# System: Modify Certificate Profile + c93bf284-a32311e5-b492895f-f9294e47, per
  missions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b492895
  f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
  privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com
nsds5ReplConflict: namingConflict cn=System: Modify Certificate Profile,cn=per
  missions,cn=pbac,dc=aws,dc=cappex,dc=com

Server #2:
# System: Modify Certificate Profile, permissions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=aws,dc=cap
  pex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
member: cn=CA Administrator,cn=privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com

# System: Modify Certificate Profile + c93bf284-a32311e5-b492895f-f9294e47, per
  missions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b492895
  f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
  privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com
nsds5ReplConflict: namingConflict cn=system: modify certificate profile,cn=per
  missions,cn=pbac,dc=aws,dc=cappex,dc=com

Server #3:
# System: Modify Certificate Profile, permissions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=aws,dc=cap
  pex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
  privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com

I realize that this is a horrible state of replication.
My question is, what happens if I modify or delete an entry on one server that 
doesn't exist on another?
Thanks.
-John



You can remove them on all servers because it is replicated, so the one 
correct (you chose) will be replicated everywhere, IIRC the conflicting 
entries are not replicated, they has just local validity, so you must 
remove those Conflict marks (see dirsrv docs I posted) and then it will 
be replicated


Probably you can remove all System:  permissions which have 
replication conflict,  ipa-server-upgrade will recreate those entries. 
However you must fix the "privilege" entries manually (like CA 
Administrator)


Please fix all conflicts before running ipa-server-upgrade, otherwise it 
may fail randomly


Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread John Popowitch 
Ok, so I'm looking at fixing the conflicts for ' System: Modify Certificate 
Profile'.
I ran this on each server:
ldapsearch -Y GSSAPI -b 'dc=aws,dc=cappex,dc=com' "cn=*Modify Certificate 
Profile*" \* nsds5ReplConflict

And now to make things interesting, this query has different results on each 
server.
Server #1:
# System: Modify Certificate Profile + c93bf284-a32311e5-b492895f-f9294e47, per
 missions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b492895
 f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
 privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com
nsds5ReplConflict: namingConflict cn=System: Modify Certificate Profile,cn=per
 missions,cn=pbac,dc=aws,dc=cappex,dc=com

Server #2:
# System: Modify Certificate Profile, permissions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=aws,dc=cap
 pex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
member: cn=CA Administrator,cn=privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com

# System: Modify Certificate Profile + c93bf284-a32311e5-b492895f-f9294e47, per
 missions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b492895
 f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
 privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com
nsds5ReplConflict: namingConflict cn=system: modify certificate profile,cn=per
 missions,cn=pbac,dc=aws,dc=cappex,dc=com

Server #3:
# System: Modify Certificate Profile, permissions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile,cn=permissions,cn=pbac,dc=aws,dc=cap
 pex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
 privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com

I realize that this is a horrible state of replication.
My question is, what happens if I modify or delete an entry on one server that 
doesn't exist on another?
Thanks.
-John


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Announcing FreeIPA 4.4.2

2016-10-13 Thread Petr Vobornik 
The FreeIPA team would like to announce FreeIPA 4.4.2 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora 24 will be available in the official COPR repository
.

This announcement is also available on
http://www.freeipa.org/page/Releases/4.4.2

Fedora 25 update:
https://bodhi.fedoraproject.org/updates/freeipa-4.4.2-1.fc25

== Highlights in 4.4.2 ==
=== Known Issues ===
* ipa-ca-install fails on replica when master is CA-less #6226
* ipa cert-find command doesn't return revocation reason in output, Web
UI then cannot display proper state of a certificate #6269

=== Bug fixes ===
FreeIPA 4.4.2 is a stabilization release for the features delivered as a
part of 4.4.0. There are more than 40 bug-fixes which details can be
seen in the list of resolved tickets below.

== Upgrading ==
Upgrade instructions are available on upgrade page
.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users
mailing list (http://www.redhat.com/mailman/listinfo/freeipa-users) or
#freeipa channel on Freenode.

== Resolved tickets ==
* 4802 Investigate & document if TLS 1.2 is properly supported
* 5557 Strict dependency of optional package pam_krb5
* 5644 dnsrecord-del incompatible with admintools < ver 3.2 and server
>= ver 3.2
* 5725 failed ipa-server-install --uninstall returns exit code 0
* 5754 ipa-client-install man page has incorrect data on hostname
* 5755 test_0006_service_show  in test_cert_plugin uses global variable
wrong
* 5809 ipa-server-install fails when using external certificates that
encapsulate RDN components in double quotes
* 5814 Change IP address validation errors to warnings [support for
cloud environments]
* 5818 webui: "Restore" option is not available for a preserved user in
detailed info
* 5822 Cannot create user with username exactly 255 charaters long
* 5855 method get_primary_key_from_dn does not work for netgroups properly
* 6057 adding two way non transitive(external) trust displays internal
error on the console
* 6095 ipa command stuck forever on higher versioned client with lower
versioned server
* 6155 [tracker] Failed to configure CA instance
* 6190 Regressions found by test: ipa.test_ipalib.test_parameters
* 6203 dnsrecord-add does not prompt for missing record parts internactively
* 6212 Pretty-print mismatches in tests
* 6216 webui: cert_revoke should use --cacn to set correct CA when
revoking certificate
* 6221 Certificate revocation in service-del and host-del isn't aware of
Sub CAs
* 6230 installer: external CA step 1 successful but reports ScriptError
* 6238 Unable to view certificates issued by Sub CA in Web UI
* 6256 [tracker] Revoke certificate on lightweight CA deletion
* 6257 Implement ca-enable/disable commands.
* 6260 cert-request: use better error message when CA is disabled
* 6273 Command autocompletion without installed server prints an error
message
* 6279 CLI always sends default command version
* 6285 Tests: Regex errors in trust tests
* 6288 ipa-certupdate fails with "CA is not configured"
* 6294 TypeError in installer
* 6296 client-install with IPv6 address fails on link-local address (always)
* 6300 Remove the assertion of incorrect return code from
replica_promotion tests
* 6301 Fix replica_promotion tests
* 6304 cert-find --certificate does not work for certificates not in LDAP
* 6306 Add cleanup to integration trust tests
* 6309 cert-request does not raise error when CSR does not match profile
pattern
* 6312 Failing ldap backend test because service not found
* 6313 Failing test in test_ipalib/test_plugable
* 6322 Add krb5kdc restart to integration trust tests
* 6323 Tests: Remove usage of krb5 ccache from test_ipaserver/test_ldap
* 6326 Update host test with ipa-join
* 6327 regression in `ipa cert-revoke --help`
* 6328 ipa trust-fetch-domains throws internal error
* 6329 WinSync users who have First.Last casing creates users who can
have their password set
* 6330 Invalid description for --hostname option in ipa-server-install
man page
* 6333 Skipped test_ipalib/test_text::test_TestLang::test_test_lang in
outoftree suite
* 6338 [Tests] Remove SSSD restart from integration tests
* 6341 Certificate UI on details page shows add button even if user
doesn't have write right
* 6349 Tests: incomplete cleanup of CA plugin XMLRPC tests
* 6366 Extend CA ACL tests for test cases with CSR containing Subject
Alt Name
* 6368 otpd doesn't properly handle closing of ldap connection
* 6373 test_util.test_assert_deepequal fails
* 6382 Test: disable test for wrong client domain in domain level 0
* 6385 ipa-server-install --external-ca fails with AttributeError
* 6390 python-dns 1.15.0 breaks FreeIPA
* 6391 make FreeIPA codebase ready for pylint in Fedora rawhide
* 5791 CA fails to start after doing ipa-ca-install --external-ca
== Detailed changelog since 4.4.1 ==
=== Christian Heimes (1) ===
* Use RSA-OAEP instead of

Re: [Freeipa-users] diskless workstations in an IPA domain

2016-10-13 Thread Jakub Hrozek 
On Thu, Oct 13, 2016 at 05:45:32PM +0200, Jacquelin Charbonnel wrote:
> Hi everybody,
> 
>   What is the best practice to enroll diskless Fedora24 workstations 
> (under
> stateless Linux) into a IPA domain ?
>   Each diskless workstation mounts its filesystem in RO mode from a single
> NFS share, with some specific directories (like /var/lib/sss) mapped RW in
> RAM.

I can't speak for other components, but /var/lib/sss/ is the only
directory sssd writes to (except tmpfiles, but I guess /tmp would also
be a writable fs?)

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Naming conventions/practices for HBAC/sudo/etc

2016-10-13 Thread Baird, Josh 
Hi all,

I realize that this with vary from instance to instance, but I'm curious on how 
others are handling naming conventions for things like HBAC rules, sudo rules, 
etc.

Here is how I am handling things today:

* External groups have an 'external' prefix (eg, external_groupname)
* Hostgroups have a $group prefix (eg, groupX_webservers)
* sudo rules are classified by the group name (eg, EmailAdmins)

This example sudo rule would allow members of the 'EmailAdmins' group access to 
run certain commands/command-groups on specific host-groups (eg, 
groupX_webservers).

* HBAC rules are classified by the group name (eg, allow_EmailAdmins)

This example HBAC rule would allow members of the 'EmailAdmins' group access to 
certain host-groups (eg, groupX_webservers).  When this group needs to access 
additional groups of servers, I just modify the existing HBAC rule and add the 
new group.  There are many different ways to handle this.  I have thought about 
classifying HBAC rules by hostgroup instead of user group.  In this case, I 
would have an HBAC rule named 'allow_Webservers' where I would specify 
individual user-groups that require access to the host(s).  My opinion on this 
is likely to change as our environment (and use cases) continues to expand.

What is working in your environment?  What would you change if you could start 
over?  It would be great if this discussion could eventually lead to a 'best 
practices' document/wiki-page for naming conventions and practices.

Thanks,

Josh



-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] diskless workstations in an IPA domain

2016-10-13 Thread Jacquelin Charbonnel 

Hi everybody,

	What is the best practice to enroll diskless Fedora24 workstations 
(under stateless Linux) into a IPA domain ?
	Each diskless workstation mounts its filesystem in RO mode from a 
single NFS share, with some specific directories (like /var/lib/sss) 
mapped RW in RAM.


Thank you for any help!
Jacquelin

--
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread John Popowitch 
Thanks so much for your help, Martin, and Alexander for keeping me honest.
I think I have enough to start working on resolving the replication conflicts.
I'm sure I'll have more questions, but this is definitely the right place to 
get them answered.

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com] 
Sent: Thursday, October 13, 2016 9:36 AM
To: John Popowitch; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors



On 13.10.2016 15:54, John Popowitch wrote:
> Also, it seems like most of these conflicts are nearly identical.
> Which leads me to believe I should delete the duplicates.
> The URL you shared seems to talk about renaming and keeping the conflicting 
> records.
> Should I rename them or remove them?

Make sure that there is exactly one right entry (from each set of conflicts), 
the best might be to rename one duplicated entry (DS will tell you if entry 
already exists as worst case) and remove other duplications.
Please note that memberOf attributes are generated dynamically so you don't 
need to change them it should be updated when you remove/update DN of entries.

Martin

>
> -Original Message-
> From: John Popowitch
> Sent: Thursday, October 13, 2016 8:50 AM
> To: 'Martin Basti'; Alexander Bokovoy
> Cc: freeipa-users@redhat.com
> Subject: RE: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to 
> run ipa-server-upgrade, but has errors
>
> Yeah, so very lucky.
> I have no idea how this happened.
> As I said before I inherited these servers so I don't really know what was 
> done to get them to this state.
> I'm guessing most if not all of the conflicts are naming conflicts for 
> standard entries which were setup on all three servers.
>
> Please help me to understand what this upgrade does.
> What does ipa-server-upgrade do?
> Each server has IPA RPMs for v4.2.0.
> Does this command upgrade RPMs?
> Does it need to be run on each server?
>
> Thanks for your help.
> -John
>
> -Original Message-
> From: Martin Basti [mailto:mba...@redhat.com]
> Sent: Thursday, October 13, 2016 2:12 AM
> To: John Popowitch; Alexander Bokovoy
> Cc: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to 
> run ipa-server-upgrade, but has errors
>
> Oh you are lucky to have ~150 replication conflicts :)
>
> How did you get those? Did you run upgrade in parallel or did you have some 
> network issues?
>
>
> You have to manually fix all replication conflicts and the re-run 
> ipa-server-upgrade
>
> Please follow guide I posted previously, sorry :(
>
>
> Martin
>


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread Martin Basti 



On 13.10.2016 15:54, John Popowitch wrote:

Also, it seems like most of these conflicts are nearly identical.
Which leads me to believe I should delete the duplicates.
The URL you shared seems to talk about renaming and keeping the conflicting 
records.
Should I rename them or remove them?


Make sure that there is exactly one right entry (from each set of 
conflicts), the best might be to rename one duplicated entry (DS will 
tell you if entry already exists as worst case) and remove other 
duplications.
Please note that memberOf attributes are generated dynamically so you 
don't need to change them it should be updated when you remove/update DN 
of entries.


Martin



-Original Message-
From: John Popowitch
Sent: Thursday, October 13, 2016 8:50 AM
To: 'Martin Basti'; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: RE: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Yeah, so very lucky.
I have no idea how this happened.
As I said before I inherited these servers so I don't really know what was done 
to get them to this state.
I'm guessing most if not all of the conflicts are naming conflicts for standard 
entries which were setup on all three servers.

Please help me to understand what this upgrade does.
What does ipa-server-upgrade do?
Each server has IPA RPMs for v4.2.0.
Does this command upgrade RPMs?
Does it need to be run on each server?

Thanks for your help.
-John

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: Thursday, October 13, 2016 2:12 AM
To: John Popowitch; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Oh you are lucky to have ~150 replication conflicts :)

How did you get those? Did you run upgrade in parallel or did you have some 
network issues?


You have to manually fix all replication conflicts and the re-run 
ipa-server-upgrade

Please follow guide I posted previously, sorry :(


Martin



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Password Complexity Requirements Seems Insufficient

2016-10-13 Thread Rob Crittenden 

Ernedin Zajko wrote:

Hi Anton,

maybe you can "talk" directly to ds:
http://directory.fedoraproject.org/docs/389ds/FAQ/password-syntax.html
regards,


That won't work. IPA re-implements password policy because it is baked 
into 389-ds and not plugable or extensible.


There are some open tickets for enhancing IPA password policies but 
other features have taken precedence thus far:


https://fedorahosted.org/freeipa/ticket/2445
https://fedorahosted.org/freeipa/ticket/5948

rob



--- Ernedin ZAJKO
  eza...@root.ba


340282366920938463463374607431768211456




On Thu, Oct 13, 2016 at 1:53 AM, Anon Lister  wrote:

Unfortunately, policy and regulation often lag behind current theory by
several decades. For what it's worth, I'd second being able to set more
complicated policies as a useful feature.


On Oct 12, 2016 6:38 PM, "Simpson Lachlan" 
wrote:



-Original Message-
From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
boun...@redhat.com] On Behalf Of Bennett, Chip
Sent: Thursday, 13 October 2016 7:21 AM
To: Florence Blanc-Renaud; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Password Complexity Requirements Seems
Insufficient

Flo,

Thanks for getting back to me.  I had seen this in the documentation.
I was just
hoping that I was missing something.   I guess I'm just surprised that a
product
designed to manage authentication wouldn't have a way to be more
specific in the
complexity requirements.



I don't know. Those type of complexity requirements are multifaceted,
complex and somewhat arbitrary. Given that each then requires regex, I'm
quite happy that the devs focus on getting other aspects of FreeIPA to work
over password complexity.

As xkcd noted a couple of years ago, password length is better for
security than anything else.

Complex arrangements of different character classes is neither human or UX
friendly nor where contemporary security theory is focused - try 2FA,
public/private keys, etc. While I understand that large organisations have
policy that often drags well behind contemporary theory, I don't think it's
fair to expect software to also allow for that.

Cheers
L.








Thanks again!
Chip

-Original Message-
From: Florence Blanc-Renaud [mailto:f...@redhat.com]
Sent: Wednesday, October 12, 2016 3:18 PM
To: Bennett, Chip ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Password Complexity Requirements Seems
Insufficient

On 10/11/2016 07:36 PM, Bennett, Chip wrote:

I just joined this list, so if this question has been asked before
(and I'll bet it has), I apologize in advance.



A google search was unrevealing, so I'm asking here: we're running
FreeIPA Version 3.0.0 on CentOS 6.6.   It looks like the password
complexity requirements are limited to setting the number of character
classes to require, i.e. setting it to "2" would require your new
password to be any two of the character classes.



What if you wanted new passwords to meet specific class requirements,
i.e. a mix of UL, LC, and numbers.  It looks like you would use a
value of "3" to accomplish this, but that would also allow UC, LC, and
special, or LC, numbers, and special, but you don't want to allow the
those:  how would you specify that?


Hi,

as far as I know, it is only possible to specify the number of different
character
classes. The doc chapter "Creating Password Policies in the Web UI" [1]
describes
the following:
---
Character classes sets the number of different categories of character
that must be
used in the password. This does not set which classes must be used; it
sets the
number of different (unspecified) classes which must be used in a
password. For
example, a character class can be a number, special character, or
capital; the
complete list of categories is in Table 22.1, "Password Policy
Settings". This is part
of setting the complexity requirements.
---

hope this clarifies,
Flo

[1]
https://access.redhat.com/documentation/en-

US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_

Policy_Guide/Setting_Different_Password_Policies_for_Different_User_Groups.ht
ml#creating-group-policy-ui





Also, what if you had a requirement for more than one of the character
classes, i.e. you want to require two UC characters or two special
characters?



Thanks in advance for the help,

Chip Bennett




This message is solely for the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited.





This message is solely for the intended recipient(s) and may contain
confidential
and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

This email (including any attachments or links)

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread Martin Basti 



On 13.10.2016 15:50, John Popowitch wrote:

Yeah, so very lucky.
I have no idea how this happened.
As I said before I inherited these servers so I don't really know what was done 
to get them to this state.
I'm guessing most if not all of the conflicts are naming conflicts for standard 
entries which were setup on all three servers.

Please help me to understand what this upgrade does.
What does ipa-server-upgrade do?
It upgrades configuration of services and LDAP data to fit the current 
version installed from RPMs.

Each server has IPA RPMs for v4.2.0.
Does this command upgrade RPMs?
No, ipa-server-upgrade is called from RPM upgrade process. First new 
RPMs are installed, then ipa-server-upgrade is executed. In your case 
ipa-server-upgrade failed so it should be rerun because there might be 
configs that needs upgrade.



Does it need to be run on each server?
Yes, as I said it is part of RPM installation. ipa-server-upgrade is 
idempotent so it can be called multiple times. I recommend to execute it 
again to be sure. (first remove conflicts)




Thanks for your help.
-John

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: Thursday, October 13, 2016 2:12 AM
To: John Popowitch; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Oh you are lucky to have ~150 replication conflicts :)

How did you get those? Did you run upgrade in parallel or did you have some 
network issues?


You have to manually fix all replication conflicts and the re-run
ipa-server-upgrade

Please follow guide I posted previously, sorry :(


Martin



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread John Popowitch 
Also, it seems like most of these conflicts are nearly identical.
Which leads me to believe I should delete the duplicates.
The URL you shared seems to talk about renaming and keeping the conflicting 
records.
Should I rename them or remove them?

-Original Message-
From: John Popowitch 
Sent: Thursday, October 13, 2016 8:50 AM
To: 'Martin Basti'; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: RE: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Yeah, so very lucky.
I have no idea how this happened.
As I said before I inherited these servers so I don't really know what was done 
to get them to this state.
I'm guessing most if not all of the conflicts are naming conflicts for standard 
entries which were setup on all three servers.

Please help me to understand what this upgrade does.
What does ipa-server-upgrade do?
Each server has IPA RPMs for v4.2.0.
Does this command upgrade RPMs?
Does it need to be run on each server?

Thanks for your help.
-John

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com]
Sent: Thursday, October 13, 2016 2:12 AM
To: John Popowitch; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Oh you are lucky to have ~150 replication conflicts :)

How did you get those? Did you run upgrade in parallel or did you have some 
network issues?


You have to manually fix all replication conflicts and the re-run 
ipa-server-upgrade

Please follow guide I posted previously, sorry :(


Martin


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread John Popowitch 
Yeah, so very lucky.
I have no idea how this happened.
As I said before I inherited these servers so I don't really know what was done 
to get them to this state.
I'm guessing most if not all of the conflicts are naming conflicts for standard 
entries which were setup on all three servers.

Please help me to understand what this upgrade does.
What does ipa-server-upgrade do?
Each server has IPA RPMs for v4.2.0.
Does this command upgrade RPMs?
Does it need to be run on each server?

Thanks for your help.
-John

-Original Message-
From: Martin Basti [mailto:mba...@redhat.com] 
Sent: Thursday, October 13, 2016 2:12 AM
To: John Popowitch; Alexander Bokovoy
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run 
ipa-server-upgrade, but has errors

Oh you are lucky to have ~150 replication conflicts :)

How did you get those? Did you run upgrade in parallel or did you have some 
network issues?


You have to manually fix all replication conflicts and the re-run 
ipa-server-upgrade

Please follow guide I posted previously, sorry :(


Martin


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Server installation on ubuntu 14.0

2016-10-13 Thread Alexander Bokovoy 

On to, 13 loka 2016, Deepak Dimri wrote:


Hi Alexander,

I have tried it on ubuntu 16.04 as well but no luck either.  Getting the same 
error:


sudo apt-get install freeipa-server

Reading package lists... Done

Building dependency tree

Reading state information... Done

E: Unable to locate package freeipa-server

any other ideas? I dont  find any good response to this issue either..

Check your repos. It is definitely part of Ubuntu 16.04:
https://launchpad.net/ubuntu/xenial/+source/freeipa

See also https://www.redhat.com/archives/freeipa-users/2016-May/msg00255.html
(and search for mailing list archives before asking questions again)

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA Server installation on ubuntu 14.0

2016-10-13 Thread Deepak Dimri 

Hi Alexander,

I have tried it on ubuntu 16.04 as well but no luck either.  Getting the same 
error:


sudo apt-get install freeipa-server

Reading package lists... Done

Building dependency tree

Reading state information... Done

E: Unable to locate package freeipa-server

any other ideas? I dont  find any good response to this issue either..

Thanks Much,
Deepak


From: Alexander Bokovoy 
Sent: Wednesday, October 12, 2016 1:40 PM
To: Deepak Dimri
Cc: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] FreeIPA Server installation on ubuntu 14.0

On ke, 12 loka 2016, Deepak Dimri wrote:
>Hi All,
>
>
>I am trying to install freeIPA server on ubuntu 14.0 but i am getting Error 
>"Unable to locate package freeipa-server" below is what  i am trying:
>
>
>apt-get install freeipa-server -y
>
>Reading package lists... Done
>
>Building dependency tree
>
>Reading state information... Done
>
>E: Unable to locate package freeipa-server
>
>
>apt-get install freeipa-client -y works just fine..
>
>
>i have tried enabling universe repository in /etc/apt/sources.list and ran 
>apt-get update but no luck either still getting Unable to locate package 
>freeipa-server.
>
>
>How can i install ipa server on ubuntu?
Use newer Ubuntu.

--
/ Alexander Bokovoy
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] bind-dyndb-ldap issues

2016-10-13 Thread Petr Spacek 
On 13.10.2016 01:42, Brendan Kearney wrote:
> On 10/12/2016 02:35 AM, Petr Spacek wrote:
>> Hello,
>>
>> these are debug messages and are harmless. Apparently you have verbose/debug
>> messages enabled in named.conf:
>>
>>  arg "verbose_checks yes";
>>
>> If you want to get rid of these messages, just remove the line.
>>
>> What version of bind-dyndb-ldap are you using?
>>
>> Sufficiently new versions should use SyncRepl to pull all data from LDAP to
>> memory (on start) so the read performance should be nearly identical as with
>> plain BIND.
>>
>> Of course, writes/DNS updates will generate load on your LDAP server so the
>> server needs to handle the load.
>>
>> Petr^2 Spacek
>>
>> On 11.10.2016 20:41, Brendan Kearney wrote:
>>> i am using bind-dyndb-ldap on fedora 24 without FreeIPA, and continue to 
>>> have
>>> my logs swamped with errors about "check failed" from settings.c and fwd.c. 
>>>  i
>>> am completely up to date with every package, so the latest versions of
>>> everything are installed.
>>>
>>> [settings.c : 420: setting_update_from_ldap_entry] check failed: ignore
>>> [settings.c : 436: setting_update_from_ldap_entry] check failed: ignore
>>> [fwd.c : 378: fwd_setting_isexplicit] check failed: not found
>>>
>>> i have two boxes running a named instance each, in a "master/master" config.
>>> each has the zone data configured per below.  the uri refers to the local ip
>>> of each server.
>>>
>>>  dynamic-db "bpk2.com" {
>>>  library "ldap.so";
>>>  arg "uri ldap://192.168.88.1/;;
>>>  arg "base cn=dns,ou=Daemons,dc=bpk2,dc=com";
>>>  arg "auth_method simple";
>>>  arg "bind_dn cn=dnsUser,dc=bpk2,dc=com";
>>>  arg "password dnsPass";
>>>
>>>  arg "fake_mname server1.bpk2.com.";
>>>  arg "dyn_update yes";
>>>  arg "connections 2";
>>>  arg "verbose_checks yes";
>>>  };
>>>
>>>  zone "." IN {
>>>  type hint;
>>>  file "named.ca";
>>>  };
>>>
>>>  include "/etc/named.rfc1912.zones";
>>>
>>> my dns container is defined in openldap as such:
>>>
>>> dn: cn=dns,ou=Daemons,dc=bpk2,dc=com
>>> cn: dns
>>> idnspersistentsearch: FALSE
>>> idnszonerefresh: 30
>>> objectclass: top
>>> objectclass: nsContainer
>>> objectclass: idnsConfigObject
>>>
>>> where and how can i find the source of my issue?  these issues are causing
>>> performance issues on the rest of my network.  because of these errors, ldap
>>> throws errors about deferred operations for binding, too many executing, and
>>> pending operations.  additionally, recursion also seems to be impacted.  
>>> this
>>> is noticed most when streaming content.  buffering, stuttering and 
>>> pixelation
>>> are seen in the video streams.  it could be the swamping of logs killing I/O
>>> or the actual recurision, but 100% the video issues are related.  the log
>>> events match up exactly with the buffering.
>>>
>>> i had this issue with bind-dyndb-ldap and fedora 20 up until i recently
>>> upgraded.  i went from F20 to F24, and put things on nice new SSDs, instead 
>>> of
>>> spinning disks.  the problem followed the upgrade.  are there configuration
>>> items i am missing?  are there tweaks i can do to improve something?  how 
>>> do i
>>> get rid of these errors, so dns performance (or the log swamping) is not
>>> affecting the rest of my network?
>>>
>>> thank you,
>>>
>>> brendan
> 
> i am running 10.1.1 on F24.
> 
> why or how would those error logs be related to LDAP seeing an influx of
> updates, 

Again, these are just debug logs. Do not get confused by word 'failed' here,
it just means that return code from a function is not ISC_R_SUCCESS. In some
cases it is expected and does not imply error condition. (You can mentally
replace word 'failed' with string 'debug: function returned ').

These two cases are just fine:
- ISC_R_IGNORE from setting_update_from_ldap_entry function means that there
was no update to particular setting in the LDAP a entry - plugin processed the
change notification from LDAP server and found nothing new.

- ISC_R_NOTFOUND from fwd_setting_isexplicit is most likely fine as well, it
is an internal function which determines if a zone has explicitly configured
forwarding. It is not :-)


> that wind up causing LDAP operations to queue up and require pended
> transactions, etc?

Again, these are not errors and certainly do not indicate anything bad.
Disable the debug logs if you do not want see it, but in any case, these are
part of normal operation.


> are there tweaks and tuning options i should have in my
> LDAP to manage this?

If you see a performance problem, you need to dig deeper. Bind-dyndb-ldap is
most likely not a root cause because it does "nothing" from performance
perspective :-) I would inspect disk I/O on the LDAP and DNS servers to see if
I/O subsystem is saturated (or not).

DNS server is keeping its transaction logs on disk so big number of

Re: [Freeipa-users] FreeIPA v4.2 stopped working, wants me to run ipa-server-upgrade, but has errors

2016-10-13 Thread Martin Basti 

Oh you are lucky to have ~150 replication conflicts :)

How did you get those? Did you run upgrade in parallel or did you have 
some network issues?



You have to manually fix all replication conflicts and the re-run 
ipa-server-upgrade


Please follow guide I posted previously, sorry :(


Martin


On 12.10.2016 21:30, John Popowitch wrote:

I ran the following on each of my three servers:
kinit admin
ldapsearch -Y GSSAPI -b 'dc=aws,dc=cappex,dc=com' "nsds5ReplConflict=*" \* 
nsds5ReplConflict
There are 49, 57, 49 entries returned by that query on the respective server.
Here is the one related to 'System: Modify Certificate Profile' from  the first 
server:

# CA Administrator + c93bf230-a32311e5-b492895f-f9294e47, privileges, pbac, aws
  .cappex.com
dn: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=priv
  ileges,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Add CA ACL+nsuniqueid=c93bf269-a32311e5-b492895f-f9294e47
  ,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Delete CA ACL+nsuniqueid=c93bf26d-a32311e5-b492895f-f9294
  e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Manage CA ACL Membership+nsuniqueid=c93bf271-a32311e5-b49
  2895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Modify CA ACL+nsuniqueid=c93bf275-a32311e5-b492895f-f9294
  e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Delete Certificate Profile+nsuniqueid=c93bf27c-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Import Certificate Profile+nsuniqueid=c93bf280-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
objectClass: groupofnames
objectClass: top
objectClass: nestedgroup
cn: CA Administrator
description: CA Administrator
nsds5ReplConflict: namingConflict cn=CA Administrator,cn=privileges,cn=pbac,dc
  =aws,dc=cappex,dc=com


Here are the related entries from the second server:

# CA Administrator + c93bf230-a32311e5-b492895f-f9294e47, privileges, pbac, aws
  .cappex.com
dn: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=priv
  ileges,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Add CA ACL+nsuniqueid=c93bf269-a32311e5-b492895f-f9294e47
  ,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Delete CA ACL+nsuniqueid=c93bf26d-a32311e5-b492895f-f9294
  e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Manage CA ACL Membership+nsuniqueid=c93bf271-a32311e5-b49
  2895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Modify CA ACL+nsuniqueid=c93bf275-a32311e5-b492895f-f9294
  e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Delete Certificate Profile+nsuniqueid=c93bf27c-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Import Certificate Profile+nsuniqueid=c93bf280-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b
  492895f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
objectClass: groupofnames
objectClass: top
objectClass: nestedgroup
cn: CA Administrator
description: CA Administrator
nsds5ReplConflict: namingConflict cn=ca administrator,cn=privileges,cn=pbac,dc
  =aws,dc=cappex,dc=com

# System: Modify Certificate Profile + c93bf284-a32311e5-b492895f-f9294e47, per
  missions, pbac, aws.cappex.com
dn: cn=System: Modify Certificate Profile+nsuniqueid=c93bf284-a32311e5-b492895
  f-f9294e47,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
member: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=
  privileges,cn=pbac,dc=aws,dc=cappex,dc=com
ipaPermTargetFilter: (objectclass=ipacertprofile)
ipaPermRight: write
ipaPermBindRuleType: permission
ipaPermissionType: V2
ipaPermissionType: MANAGED
ipaPermissionType: SYSTEM
cn: System: Modify Certificate Profile
objectClass: ipapermission
objectClass: top
objectClass: groupofnames
objectClass: ipapermissionv2
ipaPermDefaultAttr: description
ipaPermDefaultAttr: ipacertprofilestoreissued
ipaPermDefaultAttr: cn
ipaPermLocation: cn=certprofiles,cn=ca,dc=aws,dc=cappex,dc=com
nsds5ReplConflict: namingConflict cn=system: modify certificate profile,cn=per
  missions,cn=pbac,dc=aws,dc=cappex,dc=com


And from the third server:

# CA Administrator + c93bf230-a32311e5-b492895f-f9294e47, privileges, pbac, aws
  .cappex.com
dn: cn=CA Administrator+nsuniqueid=c93bf230-a32311e5-b492895f-f9294e47,cn=priv
  ileges,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Add CA ACL+nsuniqueid=c93bf269-a32311e5-b492895f-f9294e47
  ,cn=permissions,cn=pbac,dc=aws,dc=cappex,dc=com
memberOf: cn=System: Delete CA ACL+nsuniqueid=c93bf26d-a32311e5-b492895f-f9294