On 05/31/2011 01:30 AM, Colin Panisset wrote:
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?
No
- have a CoS which applies to a view that *doesn't* affect the
original
object?
No
- 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.
Not sure. ACIs are
aware of client attributes - but in this case, since
loginShell is single valued, you couldn't have two loginShell attributes
in the user entry, and use an ACI to deny one or the other based on ip
or hostname. I don't even know if that would work anyway (not sure if
you can allow/deny a search request for an attribute value).
-- C.
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users