Search Filter by Group

Hi all,

    I'm new to this list and 389 Directory, I have what I think is a simple question
but I've spent a couple of days looking for this answer without success. It could be
I'm asking the wrong question. I have a 389 installation which an application will use
to authenticate a pool of users. I was able to successfully configure the LDAP admin user
to connect and pull the list of users (ou=mygroup, dc=domain) but the problem comes up
when I want to narrow the list of possible users. Meaning, only allowing members of a
certain group to be queried and authenticated against. 

    I'm generally new to directory services, though I have some experience with
managing users through MS AD. The ou=group which contains the memberUid's is directly
above the group and users which I'm able to successfully pull. For example, the
location I need to filter users from is cn=myusergroup,ou=groups. The cn=myusergroup entry
has a drop down field called memberUid which contains the members of the group. Getting
the list of these users to work in a search filter is the problem I'm having. 

The individual entries for each user are sparsely populated with fields and don't
contain samaccountname but use UID instead. As I understand this is not a problem. Also,
in each user entry there are no references to the group which they are a part of.

   I'm using Ldapsearch to test the search filters and Apache Directory Studio to
browse the directory. In my last experience in MS AD, I believe I just added the group
attributes in each user entry as needed. Though, I'm new to 389 and want to do best
practices as opposed to workarounds. 

   Any advice you could give is very much appreciated and or recommended references. The
documentation I've found so far doesn't seem to connect.

-Saul

[Bassett.Mark]

This is what the memberOf  overlay is used for.   However it doesn't work with
posixGroup out of the gate, In order to use memberOf and posixGroup you need to use the
draft bis schema.

memberOf  allows your user record to report group membership.

Without it you must query the group directly for memberUid's.

The bis draft schema should be available here:   /usr/share/dirsrv/data/10rfc2307bis.ldif

replace your  10rfc2307.ldif  in /etc/dirsrv/schema/    and
/etc/dirsrv/slapd-instance/schema

Your groups should have objectclass groupOfNames
and then you can add users to groups using  member: uid=$uid,ou=People,dc=example,dc=com
instead of memberuid: $uid.

Then, when you query a user it will show its group membership with memberof attributes.


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....

________________________________________
From: saul.cisneros(a)gmail.com <saul.cisneros(a)gmail.com&gt;
Sent: Tuesday, May 2, 2017 9:11 AM
To: 389-users(a)lists.fedoraproject.org
Subject: [389-users] Search Filter by Group

Hi all,

    I'm new to this list and 389 Directory, I have what I think is a simple question
but I've spent a couple of days looking for this answer without success. It could be
I'm asking the wrong question. I have a 389 installation which an application will use
to authenticate a pool of users. I was able to successfully configure the LDAP admin user
to connect and pull the list of users (ou=mygroup, dc=domain) but the problem comes up
when I want to narrow the list of possible users. Meaning, only allowing members of a
certain group to be queried and authenticated against.

    I'm generally new to directory services, though I have some experience with
managing users through MS AD. The ou=group which contains the memberUid's is directly
above the group and users which I'm able to successfully pull. For example, the
location I need to filter users from is cn=myusergroup,ou=groups. The cn=myusergroup entry
has a drop down field called memberUid which contains the members of the group. Getting
the list of these users to work in a search filter is the problem I'm having.

The individual entries for each user are sparsely populated with fields and don't
contain samaccountname but use UID instead. As I understand this is not a problem. Also,
in each user entry there are no references to the group which they are a part of.

   I'm using Ldapsearch to test the search filters and Apache Directory Studio to
browse the directory. In my last experience in MS AD, I believe I just added the group
attributes in each user entry as needed. Though, I'm new to 389 and want to do best
practices as opposed to workarounds.

   Any advice you could give is very much appreciated and or recommended references. The
documentation I've found so far doesn't seem to connect.

-Saul
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC
and/or its subsidiaries and may contain proprietary, confidential or trade secret
information. This message is intended solely for the use of the addressee. If you are not
the intended recipient and have received this message in error, please delete this message
from your system. Any unauthorized reading, distribution, copying, or other use of this
message or its attachments is strictly prohibited.

Thank you very much for the quick reply! I'll follow your directions. It has made my
understanding things much clearer. We have the objectclass,
"groupofuniquenames". I'm guessing that won't effect the outcome.

-Saul

[Bassett.Mark]

Only difference with groupofuniquenames is it uses uniqueMember: for membership as opposed
to member:
________________________________________
From: saul.cisneros(a)gmail.com <saul.cisneros(a)gmail.com&gt;
Sent: Tuesday, May 2, 2017 11:48 AM
To: 389-users(a)lists.fedoraproject.org
Subject: [389-users] Re: Search Filter by Group

Thank you very much for the quick reply! I'll follow your directions. It has made my
understanding things much clearer. We have the objectclass,
"groupofuniquenames". I'm guessing that won't effect the outcome.

-Saul
_______________________________________________
389-users mailing list -- 389-users(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org

CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC
and/or its subsidiaries and may contain proprietary, confidential or trade secret
information. This message is intended solely for the use of the addressee. If you are not
the intended recipient and have received this message in error, please delete this message
from your system. Any unauthorized reading, distribution, copying, or other use of this
message or its attachments is strictly prohibited.

[William Brown]

On Tue, 2017-05-02 at 16:38 +0000, Bassett.Mark wrote:
>  This is what the memberOf  overlay is used for.   However it
> doesn't work with posixGroup out of the gate, In order to use memberOf and posixGroup
> you need to use the draft bis schema.
>  
>  memberOf  allows your user record to report group membership.
>  
>  Without it you must query the group directly for memberUid's.
>  
>  The bis draft schema should be available here:  
> /usr/share/dirsrv/data/10rfc2307bis.ldif
>  
>  replace your  10rfc2307.ldif  in /etc/dirsrv/schema/    and
> /etc/dirsrv/slapd-instance/schema
>  
>  Your groups should have objectclass groupOfNames
>  and then you can add users to groups using  member: uid=$uid,ou=People,dc=example,dc=com
>  instead of memberuid: $uid.
>  
>  Then, when you query a user it will show its group membership with memberof attributes.
Hey there,

We ship groupOfNames in 00core.ldif with the following comment:

# NOTE: There is one very important deviation from the LDAP standard:
# there is a bug in the standard definition of groupOfNames and
# groupOfUniqueNames - the member/uniqueMember attribute is in the MUST
# list, not the MAY list, which means you cannot have an empty group.
# Until the LDAP community figures out how to do grouping properly, we
# have put the member/uniqueMember attribute into the MAY list, to allow
# empty groups.


So groupOfNames on a posixGroup, with member: dn, should "just work" out
of the box. You only need to enable memberOf Plugin and run the fix up
task to get everything in order. 

Hope that helps,

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Bassett.Mark]

That is interesting.  I wonder if we are using a modified 00core.ldif then.  I was unable
to apply member attributes until I changed to the bis draft format.

Will have to do a little more investigation.

Thanks William.
________________________________________
From: William Brown <wibrown(a)redhat.com&gt;
Sent: Tuesday, May 2, 2017 4:32 PM
To: General discussion list for the 389 Directory server project.
Subject: [389-users] Re: Search Filter by Group

On Tue, 2017-05-02 at 16:38 +0000, Bassett.Mark wrote:
>  This is what the memberOf  overlay is used for.   However it
> doesn't work with posixGroup out of the gate, In order to use memberOf and posixGroup
> you need to use the draft bis schema.
>
>  memberOf  allows your user record to report group membership.
>
>  Without it you must query the group directly for memberUid's.
>
>  The bis draft schema should be available here:  
> /usr/share/dirsrv/data/10rfc2307bis.ldif
>
>  replace your  10rfc2307.ldif  in /etc/dirsrv/schema/    and
> /etc/dirsrv/slapd-instance/schema
>
>  Your groups should have objectclass groupOfNames
>  and then you can add users to groups using  member: uid=$uid,ou=People,dc=example,dc=com
>  instead of memberuid: $uid.
>
>  Then, when you query a user it will show its group membership with memberof attributes.
Hey there,

We ship groupOfNames in 00core.ldif with the following comment:

# NOTE: There is one very important deviation from the LDAP standard:
# there is a bug in the standard definition of groupOfNames and
# groupOfUniqueNames - the member/uniqueMember attribute is in the MUST
# list, not the MAY list, which means you cannot have an empty group.
# Until the LDAP community figures out how to do grouping properly, we
# have put the member/uniqueMember attribute into the MAY list, to allow
# empty groups.


So groupOfNames on a posixGroup, with member: dn, should "just work" out
of the box. You only need to enable memberOf Plugin and run the fix up
task to get everything in order.

Hope that helps,

--
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane


CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC
and/or its subsidiaries and may contain proprietary, confidential or trade secret
information. This message is intended solely for the use of the addressee. If you are not
the intended recipient and have received this message in error, please delete this message
from your system. Any unauthorized reading, distribution, copying, or other use of this
message or its attachments is strictly prohibited.

[William Brown]

On Tue, 2017-05-02 at 23:38 +0000, Bassett.Mark wrote:
>  That is interesting.  I wonder if we are using a modified 00core.ldif
> then.  I was unable to apply member attributes until I changed to the bis draft format.
>  
>  Will have to do a little more investigation. 
It could be that schema didn't upgrade properly on your instance over
versions. It's worth checking your instance schema vs
your /usr/share/dirsrv schema.

I know that I am able to do this on a "fresh" install of DS out of box,
so I would suspect that first :) 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

Hi all,

I want to thank you all for taking the time to give me the information I needed. I was
able to get going in the right direction afterwards.

In the end, the solutuion was to move the ldif files, enable the plug-in, run the fix-up,
add objectclass, inetuser and add attribute memberof to each class. At the time when I got
it to work, my understanding was still missing since, my interpretation was that after
running the fix up, the query would work, but this was not the case.

After working with it a bit more over the week and adding another group, I think I have
been able to piece together why I had problems. Mark, I did not fully understand what you
mentioned until I saw it working. A few more questions are raised based on what I see. 

My understanding at this point is that the instructions did not work right off the bat
because our groups are not using a consistent objectclass and attribute convention. Some
groups have objectclass, groupofuniquenames and memberuid with no DN only memberUID.
Others have groupofnames with member and full DN. These seem to be the ones that work
correctly. When I added a user to the group that has objectclass, groupofnames and member
attribute, the user entry automatically populates memberOf with the full DN listed. 

After I made the updates to that group and user entries for reflect groupofnames and
member, I was able to run the filter query without any problems. At his point, I'm
thinking it would be best to add the groupofnames objectclass and member attribute to the
other groups to ensure everything operates in a similar way. Fortunately this is part of a
new envrionment (with imported data) so I have the luxury of bringing each application in
one by one over a period of time. Is there a possibility to that I would run into any
problems with that plan?

Am I correct in thinking that the schema should have added the objectclass and attributes
automatically? If so, I was going to spend some time looking into that. 

It looks like my understanding would greatly increased by reading more of the
documentation. I've noticed that there are at least a few RFC's which define the
proper behaviour, so I'll be reading those next.

William, thank you for your input as well! Your statement about the LDAP community not
implmenting groups properly make me wonder, what is the point of contention why it would
not function correctly out of the box? Is their disagreement about how RFC standards are
to be implmented? This whole thing just seems kinda unusual to me. I see your point about
it working right off in my case. I think the issue was that for whatever reason, DN was
not used but the memberUID.

I don't know if you all would have any information about this but is there a
standard/popular self service UI that is recommended for users to manage their passwords?

Thanks again!

-Saul

[Bassett.Mark]

>  When I added a user to the group that has objectclass, groupofnames
> and member attribute, the user entry automatically populates memberOf with the full DN
> listed. 
Good, that is the expected behavior.

> After I made the updates to that group and user entries for reflect
> groupofnames and member, I was able to run the filter query without any problems. At his
> point, I'm thinking it would be best to add the groupofnames objectclass and member
> attribute >to the other groups to ensure everything operates in a similar way.
> Fortunately this is part of a new envrionment (with imported data) so I have the luxury of
> bringing each application in one by one over a period of time. Is there a possibility to
> that I >would run into any problems with that plan? 
If groupofNames is how your memberof is configured (sounds like it is)  then yes you need
to add groupofNames to all your groups

> Am I correct in thinking that the schema should have added the
> objectclass and attributes automatically? If so, I was going to spend some time looking
> into that. 
No, schema basically controls what *can* be set.  Which attributes are required, and which
ones are not, etc.  It doesn't make any changes to your existing groups/users.  You
have to do that yourself.


> William, thank you for your input as well! 
William's main
point was that you shouldn't have to use the bis draft schema to get this to work on
stock ds389.  you may try reverting to the original schema and see if you continue to have
success.
I have yet to attempt to roll back to the original schema myself yet.

CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC
and/or its subsidiaries and may contain proprietary, confidential or trade secret
information. This message is intended solely for the use of the addressee. If you are not
the intended recipient and have received this message in error, please delete this message
from your system. Any unauthorized reading, distribution, copying, or other use of this
message or its attachments is strictly prohibited.

[William Brown]

On Mon, 2017-05-08 at 16:37 +0000, saul.cisneros(a)gmail.com wrote:
>  Hi all,
>  
>  I want to thank you all for taking the time to give me the information I needed. I was
> able to get going in the right direction afterwards.
>  
>  In the end, the solutuion was to move the ldif files, enable the plug-in, run the fix-up,
> add objectclass, inetuser and add attribute memberof to each class. At the time when I got
> it to work, my understanding was still missing since, my interpretation was that after
> running the fix up, the query would work, but this was not the case.
>   
In the future this will get even easier: we just added a new objectClass
"nsmemberof", which will be automatically added to your objects if a
memberOf attribute needs to be given to them. Hopefully, it should be as
simple as just enable the plugin and run the fix up soon. (1.3.7 should
contain this). 

>  After working with it a bit more over the week and adding another
> group, I think I have been able to piece together why I had problems. Mark, I did not
> fully understand what you mentioned until I saw it working. A few more questions are
> raised based on what I see. 
>  
>  My understanding at this point is that the instructions did not work right off the bat
> because our groups are not using a consistent objectclass and attribute convention. Some
> groups have objectclass, groupofuniquenames and memberuid with no DN only memberUID.
> Others have groupofnames with member and full DN. These seem to be the ones that work
> correctly. When I added a user to the group that has objectclass, groupofnames and member
> attribute, the user entry automatically populates memberOf with the full DN listed. 
>   
Well, with memberUid the issue is that we don't know who it is. In a
directory it's valid to have the same RDN, but in unique DNs. IE.

uid=william,ou=People,dc=example,dc=com
uid=william,ou=Accounts,dc=example,dc=com

memberUid only uses:

memberuid: william

So which "william" do we want to include in the group for member of
now? 

That's why we expect and use uniqueMember, or member, as there is no
ambiguity. The distinction between uniqueMember and member doesn't
affect 99% of people, so use member: groupofnames. 

>  After I made the updates to that group and user entries for reflect
> groupofnames and member, I was able to run the filter query without any problems. At his
> point, I'm thinking it would be best to add the groupofnames objectclass and member
> attribute to the other groups to ensure everything operates in a similar way. Fortunately
> this is part of a new envrionment (with imported data) so I have the luxury of bringing
> each application in one by one over a period of time. Is there a possibility to that I
> would run into any problems with that plan?
>  
>  Am I correct in thinking that the schema should have added the objectclass and attributes
> automatically? If so, I was going to spend some time looking into that. 
>  
>  It looks like my understanding would greatly increased by reading more of the
> documentation. I've noticed that there are at least a few RFC's which define the
> proper behaviour, so I'll be reading those next.
>   
I hope this reading helps you. Ultimately, as a project we want 389ds to
"just work" for you, so hearing about issues like this gives me some
ideas for improvements we can make to ease this pain. 

>  William, thank you for your input as well! Your statement about the
> LDAP community not implmenting groups properly make me wonder, what is the point of
> contention why it would not function correctly out of the box? Is their disagreement about
> how RFC standards are to be implmented? This whole thing just seems kinda unusual to me. I
> see your point about it working right off in my case. I think the issue was that for
> whatever reason, DN was not used but the memberUID.
>   
I think that largely the LDAP community is one with a long history, and
ideas that people thought would work in the past, no longer work now. So
as a result, there is a lot of history and features we have to support
for legacy, all the while trying to promote newer / better ways to do
things. There are certainly some disagreements on some items, and while
technically we may be in violation of certain RFC's for altering schema,
I think that it's better to improve usability of a system, rather than
making things hardline-correct. 

>  I don't know if you all would have any information about this but
> is there a standard/popular self service UI that is recommended for users to manage their
> passwords?
>   
I am personally not sure, but we are thinking about this space as a team
at the moment. 

>  Thanks again!
>  
>  -Saul
>  
>  
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org 
-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Bassett.Mark]

> > I don't know if you all would have any information about this
> but is there a standard/popular self service UI that is recommended for users to manage
> their passwords?
> > 
> I am personally not sure, but we are thinking about this space as a
> team
> at the moment. 

We use  https://github.com/ltb-project/self-service-password

CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC
and/or its subsidiaries and may contain proprietary, confidential or trade secret
information. This message is intended solely for the use of the addressee. If you are not
the intended recipient and have received this message in error, please delete this message
from your system. Any unauthorized reading, distribution, copying, or other use of this
message or its attachments is strictly prohibited.

[Patrick Landry]

We have had good success with PWM. It is not trivial to configure but it 
is a very complete solution and has been very stable once we put it in to 
production. 

https://github.com/pwm-project/pwm/ 

----- Original Message -----

>  From: "William Brown" <wibrown(a)redhat.com&gt;
>  To: "General discussion list for the 389 Directory server project."
>  <389-users(a)lists.fedoraproject.org&gt;
>  Sent: Monday, May 8, 2017 6:23:27 PM
>  Subject: [389-users] Re: Search Filter by Group 
>  On Mon, 2017-05-08 at 16:37 +0000, saul.cisneros(a)gmail.com wrote:
>  > I don't know if you all would have any information about
> this but is there
>  > a standard/popular self service UI that is recommended for users to manage
>  > their passwords?
>  > 
-- 
	

	

Patrick Landry 
Director, UCSS 
University of Louisiana at Lafayette 
pml(a)louisiana.edu