On 07/22/2015 07:10 AM, Paul Tobias wrote:
On 21/07/15 15:21, Rich Megginson wrote:
On 07/21/2015 06:19 AM, Paul Tobias wrote:
Hi guys,
In short: Can I use Class of Service[1] together with Host Based Attributes[2]? It doesn't work for me.
The directory server uses Host Based Attributes to give different loginshell on servers and desktops. The idea is that on a desktop machine a user can use /bin/bash as the shell. But on a server the users get /bin/bash4, which is a patched bash with audit logging. (And is not installed on desktops).
So a user entry looks like this:
dn: uid=paul.tobias,ou=People,dc=example,dc=com
loginShell: /bin/bash
loginShell;bash4: /bin/bash4
And then on a server there is this line in sssd.conf:
ldap_user_shell = loginShell;bash4
And everybody is happy.
The problem is I have to remember to add the `loginShell` and `loginShell;bash4` attributes to all new users, otherwise the user cannot log in and not everybody is happy.
To achieve this I've added Class of Service to have defaults for both of those loginshell attributes like this:
dn: cn=user defaults cos,ou=people,dc=example,dc=com
costemplatedn: cn=cos template,cn=user defaults cos,ou=people,dc=example,dc=com
cosattribute: loginshell
cosattribute: loginshell;bash4 override
And the matching template:
dn: cn=cos template,cn=user defaults cos,ou=people,dc=example,dc=com
loginshell: /bin/bash
loginshell;bash4: /bin/bash4
After this I deleted both `loginShell` and `loginShell;bash4` attributes from the user entries. And this works well for the `loginshell` attribute, ldapsearch returns `loginShell: /bin/bash`, even if the user doesn't have `loginShell` at all, this is exactly what I want. But it doesn't work for the `loginshell;bash4` attribute, ldapsearch doesn't return `loginShell;bash4`, even if I try to query it directly. Is this a limitation of the implementation or am I doing something wrong?
Sounds like https://fedorahosted.org/389/ticket/69
Yes, that's exactly what I'm seeing.
Is there a way then to have something like triggers? If a new user is created, then something gets called and adds the missing attributes to the new user? This trigger thing would also be useful if a user gets locked out because of too many failed password attempts. It would be great to send a warning email in that case.
I tried to search for something, but no luck. I could keep watching the audit log and trigger actions based on that, but that sounds ugly, is there a better way?
Not really better in the sense that 389 won't do this for you automatically.
You could use the USN feature, then poll periodically for updates:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Tracking_Modifications_to_Directory_Entries.html
You could use the Retro Changelog + persistent search.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Using_the_Retro_Changelog_Plug_in.html
You could 389 as a SyncRepl provider if you are using 1.3.3 or later,
but this is similar to Retro Changelog + persistent search.
http://www.port389.org/docs/389ds/design/content-synchronization-plugin.html
Have a nice day,
Paul
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
