Re: [389-users] Some bind DNs sporadically can't search users

2014-03-04 Thread Morgan Jones 



On Mar 4, 2014, at 3:20 AM, Ludwig Krispenz  wrote:

>>> Are groups involved in the acis and do these groups during these runs ?
>> Yes, most of our ACIs use groups to determine access.  I'm not sure I 
>> understand the second part of your question though.
> you can't, it was incomplete. I wanted to know if these groups are modified 
> during the runs when you see the failure.
>>  I do suspect this has something to do with access control though as it's 
>> behaving exactly like the user is denied by the ACIs.

No, groups were not modified.  They are relatively small as we're still 
migrating to this environment--maybe 10-15 DNs per group and they're only 
modified when we add/remove privileged accounts which isn't very often.

>>> Could you post your acis ?
>> Probably.  I'm working on permission to do so.

The compromise I came to with my management and security team is to obfuscate 
the ACIs such that the attribute counts and structure are intact but the names 
are changed.  Is the below useful?

# Employee LDAP Access Control
#
dn: dc=domain,dc=org
changetype: modify
replace: aci
#
aci: (target = "ldap:///ou=employees,dc=domain,dc=org";)
 (targetattr = "userpassword")
 (version 3.0; acl "limited user self write";
 allow (write) userdn = "ldap:///self";;)
#
aci: (target = "ldap:///dc=domain,dc=org"; )
 (targetfilter = 
"(|(objectclass=orgAssociate)(objectclass=orgEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))")
 (targetattr = "attr1 || attr2 || ... || attr40")
 (version 3.0; acl "general access, replaces anonymous access"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self";) or 
 (groupdn = "ldap:///cn=orgGroup1,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=orgGroup3,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org";) or 
 (groupdn = "ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org";)
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org"; )
 (targetfilter = "(|(objectclass=orgExternalEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=groupofuniquenames))")
 (targetattr = "attr1 || attr2 || ... || attr40 ")
 (version 3.0; acl "general access, replaces anonymous access"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self";) or 
 (groupdn = "ldap:///cn=orgGroup2,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org";) or 
 (groupdn = "ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org";)
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org";)
 (targetfilter = "(|(objectclass=orgExternalEmployee)(objectclass=domain)
 
(objectclass=organizationalunit)(objectclass=groupofnames)(objectclass=orgServiceAccount)(objectclass=orgOrgAccount))")
 (targetattr = "attr1 || attr2 || ... || attr40")
 (version 3.0; acl "general access plus service and organizational accounts"; 
 allow (read, search, compare) 
 (userdn = "ldap:///self";) or 
 (groupdn = "ldap:///cn=OrgGroup3,ou=groups,dc=domain,dc=org";) or
 (groupdn = "ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org";) or 
 (groupdn = "ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org";)
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org";)(targetattr = "attr1 ||
 attr2 || ... || attr30")
 (version 3.0; acl "limited read access to non-public attributes for delegated 
admins"; 
 allow (read, search, compare)
 (groupdn = "ldap:///cn=orgGroup4,ou=groups,dc=domain,dc=org";) or 
 (groupdn = "ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org";)
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org";)
 (targetattr = "attr1 || attr2 || ... || attr28")
 (version 3.0; acl "limited write access for delegated admins"; 
 allow (write) groupdn = "ldap:///cn=orgGroup5,ou=groups,dc=domain,dc=org";;)
#
aci: (target = "ldap:///dc=domain,dc=org";)
 (targetattr = "*")(version 3.0; acl "full access for delegated admins"; 
 allow (all) groupdn = "ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org";;)
#
aci: (target = "ldap:///dc=domain,dc=org";)
 (targetfilter="(memberof=cn=orgGroup6,ou=Groups,dc=domain,dc=org)")
 (targetattr="userpassword")
 (version 3.0; acl "deny non-admin user write access to admin users' passwords";
 deny (all) groupdn != "ldap:///cn=orgGroup6,ou=groups,dc=domain,dc=org";
 ;)
#
aci: (target = "ldap:///dc=domain,dc=org";)
 (targetattr = "attr1 || attr2 || ... || attr19")
 (version 3.0; acl "access to posixaccount attributes for proxyagent";
 allow (read,search,compare) userdn = 
"ldap:///uid=binddn1,ou=svc_accts,dc=domain,dc=org";;)

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Kerberized admin server

2014-03-04 Thread Rich Megginson 

On 03/04/2014 10:26 AM, Paul Robert Marino wrote:

On Tue, Mar 4, 2014 at 12:13 PM, Rich Megginson  wrote:

On 03/04/2014 09:16 AM, Paul Robert Marino wrote:

hello
I know there use to be a document on doing this because I did it
several years ago at a previous job but I cant seem to find it in the
documentation now.

I'm trying to make the the admin server accept Kerberos
authentication.


 From which applications?

389-console


I don't even know if that is possible, without changing the console and 
admin server code.





my kerberos servers are separate from my LDAP servers
so this shouldn't cause an issue but I just cant find the doc on how
to do it. I know I have to set KRB5_KTNAME in
/etc/sysconfig/dirsrv-admin but beyond that Im just not sure.
Do I need a specific principal in the key tab file other than
ldap/@ and do I need to set any other options in
the configuration?

if any one knows the answer or know of a doc that describes it that
would be extremely helpful.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

[389-users] Kerberized admin server

2014-03-04 Thread Paul Robert Marino 
hello
I know there use to be a document on doing this because I did it
several years ago at a previous job but I cant seem to find it in the
documentation now.

I'm trying to make the the admin server accept Kerberos
authentication. my kerberos servers are separate from my LDAP servers
so this shouldn't cause an issue but I just cant find the doc on how
to do it. I know I have to set KRB5_KTNAME in
/etc/sysconfig/dirsrv-admin but beyond that Im just not sure.
Do I need a specific principal in the key tab file other than
ldap/@ and do I need to set any other options in
the configuration?

if any one knows the answer or know of a doc that describes it that
would be extremely helpful.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users

Re: [389-users] Some bind DNs sporadically can't search users

2014-03-04 Thread Ludwig Krispenz 


On 03/03/2014 08:08 PM, Morgan Jones wrote:

On Mar 3, 2014, at 11:07 AM, Ludwig Krispenz  wrote:


Hi,

so you say that a search with a specific bind user sometimes succeeds and 
sometimes doesn't ?

Correct.


If so, could you run this withe aci logging enabled ?

Sure though we are still unable to repeat the problem reliably so haven't 
caught it happening with aci debugging turned on.  I'm going to work on various 
scenarios to do so in our dev environment.


Are groups involved in the acis and do these groups during these runs ?

Yes, most of our ACIs use groups to determine access.  I'm not sure I 
understand the second part of your question though.
you can't, it was incomplete. I wanted to know if these groups are 
modified during the runs when you see the failure.

  I do suspect this has something to do with access control though as it's 
behaving exactly like the user is denied by the ACIs.


Could you post your acis ?

Probably.  I'm working on permission to do so.

thanks,

-morgan

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users