How to use Host Based Attributes with Class of Service

[Paul Tobias]

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?

Have a nice day,
Paul

[1] http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice....
[2] http://www.port389.org/docs/389ds/howto/howto-hostbasedattributes.html

[Rich Megginson]

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

>  Have a nice day,
>  Paul
>
>  [1] http://directory.fedoraproject.org/docs/389ds/howto/howto-classofservice....
>  [2] http://www.port389.org/docs/389ds/howto/howto-hostbasedattributes.html
>  --
>  389 users mailing list
>  389-users(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users

[Paul Tobias]

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

[Rich Megginson]

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...

You could use the Retro Changelog + persistent search. 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/389-users