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.
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.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
05-31-2011, 01:59 PM
Rich Megginson
Views, Filtered roles and CoS
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@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
05-31-2011, 03:45 PM
Andrey Ivanov
Views, Filtered roles and CoS
Hi Colin,
you can use two different attributes (or the subtypes of an attribute). But it implies that the nss_ldap configuration file on development servers is different. That's the way we do it. Example:
the user entry :
dn: uid=test.user,ou=People,dc=example,dc=com
If you use RedHat/CentOS 5.x the only difference between the nss_ldap configuration files (/etc/ldap.conf) will be the mapping part on development servers :
nss_map_attribute loginShell loginShell;devel
This example uses the attribute subtype ';devel' but you are free to choose anything you like.
It's not a pure ldap solution, but rather a mix of ldap and server-side solution. Don't know whether it helps you but that's how we use it (this way,the same ldap user may have several "personalized" posix attributes depending on the /etc/ldap.conf configuration of the server) :
2011/5/31 Colin Panisset <colin.panisset@rea-group.com>
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
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
05-31-2011, 10:50 PM
Colin Panisset
Views, Filtered roles and CoS
That's *exactly* what I need to do, and a solution that works perfectly
for me.
Thanks!
-- C.
On 1/06/11 1:45 AM, Andrey Ivanov wrote:
> Hi Colin,
>
> you can use two different attributes (or the subtypes of an attribute).
> But it implies that the nss_ldap configuration file on development
> servers is different. That's the way we do it. Example:
>
> the user entry :
> dn: uid=test.user,ou=People,dc=example,dc=com
> loginShell: /bin/rbash
> loginShell;devel: /bin/bash
> uid: test.user
> ...
>
> If you use RedHat/CentOS 5.x the only difference between the nss_ldap
> configuration files (/etc/ldap.conf) will be the mapping part on
> development servers :
> nss_map_attribute loginShell loginShell;devel
>
> This example uses the attribute subtype ';devel' but you are free to
> choose anything you like.
>
> It's not a pure ldap solution, but rather a mix of ldap and server-side
> solution. Don't know whether it helps you but that's how we use it (this
> way,the same ldap user may have several "personalized" posix attributes
> depending on the /etc/ldap.conf configuration of the server) :
> nss_map_attribute uidNumber uidNumber;devel
> nss_map_attribute gidNumber gidNumber;devel
> nss_map_attribute homeDirectory homeDirectory;devel
> nss_map_attribute loginShell loginShell;devel
>
> @+
>
> 2011/5/31 Colin Panisset <colin.panisset@rea-group.com
> <mailto:colin.panisset@rea-group.com>>
>
> 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
>
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
10-06-2011, 03:23 PM
Rich Megginson
Views, Filtered roles and CoS
On 05/31/2011 09:45 AM, Andrey Ivanov wrote:
Hi Colin,
you can use two different attributes (or the subtypes of an
attribute). But it implies that the nss_ldap configuration file on
development servers is different. That's the way we do it.
Example:
the user entry :
dn: uid=test.user,ou=People,dc=example,dc=com
loginShell: /bin/rbash
loginShell;devel: /bin/bash
uid: test.user
...
If you use RedHat/CentOS 5.x the only difference between the
nss_ldap configuration files (/etc/ldap.conf) will be the
mapping part on development servers :
nss_map_attribute loginShell loginShell;devel
This example uses the attribute subtype ';devel' but you are
free to choose anything you like.
It's not a pure ldap solution, but rather a mix of ldap and
server-side solution. Don't know whether it helps you but that's
how we use it (this way,the same ldap user may have several
"personalized" posix attributes depending on the /etc/ldap.conf
configuration of the server) :
Views, Filtered roles and CoS
