[389-users] Views, Filtered roles and CoS

Colin Panisset colin.panisset at rea-group.com
Tue May 31 07:30:27 UTC 2011


I have a pretty flat DIT, with all users currently under
ou=people,dc=example,dc=com; these user objects also have posixAccount
attributes, of which loginShell is one.

What I'm trying to achieve is to be able to set a "default" loginShell
to be a restricted shell (/bin/rbash) for developers, but allow that to
be a non-restricted shell on systems which are development hosts.

As an example, on a production host I'd like:

$ ldapsearch -x "(uid=devuser)" uid loginshell

to return:

dn: cn=Dev User,ou=People,dc=example,dc=com
loginShell: /bin/rbash
uid: devuser

while on a development host, I'd like the same search to return

dn: cn=Dev User,ou=People,dc=example,dc=com
loginShell: /bin/bash
uid: devuser

I thought I might be able to achieve this by creating a view called
ou=Developers,dc=example,dc=com and using that as a base DN on the
development boxes, then applying a CoS within the view to override the
loginShell attribute, but then the CoS ends up being applied to the
original entry too.

Is there any way that I could:

- have a CoS apply based on client system attributes, like IP
address/hostname?
- have a CoS which applies to a view that *doesn't* affect the original
object?
- perhaps make use of cosPriority through two different views, so as to
have ou=Development,... and ou=Production,... (but that would be
answered by the previous option anyway)?

Is there some other clever way to achieve what I'd like? I'd really like
to avoid maintaining 2 separate DITs for the same set of users.

  -- C.



More information about the 389-users mailing list