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 together with Host Based Attributes?
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
>> 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:
You could use the Retro Changelog + persistent search.
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.
Have a nice day,
389 users mailing list