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?
Have a nice day,
Paul