On Mon, 2017-05-08 at 16:37 +0000, saul.cisneros@xxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
