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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
