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.
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
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
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
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
So, as a followup, I'm now trying to combine this with role-based CoS overrides, but it's not working.
I'd like to set the loginshell;devel attribute-subtype via a filtered role so that I can maintain it in a single place
I have this classic Cos definition:
dn: cn=cosOverrideDevShell,dc=example,dc=com cosAttribute: loginshell;devel override objectClass: cosClassicDefinition objectClass: cosSuperDefinition objectClass: ldapSubEntry objectClass: top cosspecifier: nsRole costemplatedn: cn=cosTemplates,dc=example,dc=com cn: cosOverrideDevShell
which references templates in this container:
dn: cn=cosTemplates,dc=example,dc=com cn: cosTemplates objectClass: top objectClass: nscontainer
The only template in the container is:
dn: cn=cn\3DDeveloper\2Cdc\3Dexample\2Cdc\3Dcom,cn= cosTemplates,dc=example,dc=com cn: cn=Developer,dc=example,dc=com loginShell;devel: /bin/bash objectClass: top objectClass: costemplate objectClass: extensibleobject
which references this Role:
dn: cn=Developer,dc=example,dc=com nsRoleFilter: (objectclass=person) objectClass: top objectClass: ldapsubentry objectClass: nsroledefinition objectClass: nscomplexroledefinition objectClass: nsfilteredroledefinition cn: Developer
and yet the loginshell;devel attribute-subattribute doesn't get set.
I'm looking with ldapsearch:
$ ldapsearch -x "(nsrole=cn=developer,dc=example,dc=com)" loginshell;devel
but it's never set.
I've tested the syntax of my templates and definitions by adding a second cosAttribute to the definition, thus:
cosAttribute: mobile override
and then adding the attribute to the template:
mobile: +123456
and an ldapsearch *does* show the mobile attribute being set for that set of users, but not the loginshell;devel attribute overriden by the same template.
This isn't a showstopper, I can update every entry to add the loginshell;devel subattribute, but I'd much prefer to have it set dynamically, as this will then prevent future account creation mishaps.
Is this something I should be able to do?
-- C.
On 1/06/11 8:50 AM, Colin Panisset wrote:
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
On 05/31/2011 08:41 PM, Colin Panisset wrote:
So, as a followup, I'm now trying to combine this with role-based CoS overrides, but it's not working.
I'd like to set the loginshell;devel attribute-subtype via a filtered role so that I can maintain it in a single place
I have this classic Cos definition:
dn: cn=cosOverrideDevShell,dc=example,dc=com cosAttribute: loginshell;devel override objectClass: cosClassicDefinition objectClass: cosSuperDefinition objectClass: ldapSubEntry objectClass: top cosspecifier: nsRole costemplatedn: cn=cosTemplates,dc=example,dc=com cn: cosOverrideDevShell
which references templates in this container:
dn: cn=cosTemplates,dc=example,dc=com cn: cosTemplates objectClass: top objectClass: nscontainer
The only template in the container is:
dn: cn=cn\3DDeveloper\2Cdc\3Dexample\2Cdc\3Dcom,cn= cosTemplates,dc=example,dc=com cn: cn=Developer,dc=example,dc=com loginShell;devel: /bin/bash objectClass: top objectClass: costemplate objectClass: extensibleobject
which references this Role:
dn: cn=Developer,dc=example,dc=com nsRoleFilter: (objectclass=person) objectClass: top objectClass: ldapsubentry objectClass: nsroledefinition objectClass: nscomplexroledefinition objectClass: nsfilteredroledefinition cn: Developer
and yet the loginshell;devel attribute-subattribute doesn't get set.
I'm looking with ldapsearch:
$ ldapsearch -x "(nsrole=cn=developer,dc=example,dc=com)" loginshell;devel
but it's never set.
I've tested the syntax of my templates and definitions by adding a second cosAttribute to the definition, thus:
cosAttribute: mobile override
and then adding the attribute to the template:
mobile: +123456
and an ldapsearch *does* show the mobile attribute being set for that set of users, but not the loginshell;devel attribute overriden by the same template.
This isn't a showstopper, I can update every entry to add the loginshell;devel subattribute, but I'd much prefer to have it set dynamically, as this will then prevent future account creation mishaps.
Is this something I should be able to do?
https://bugzilla.redhat.com/show_bug.cgi?id=668808
-- C.
On 1/06/11 8:50 AM, Colin Panisset wrote:
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
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
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) : nss_map_attribute uidNumber uidNumber;devel nss_map_attribute gidNumber gidNumber;devel nss_map_attribute homeDirectory homeDirectory;devel nss_map_attribute loginShell loginShell;devel
@+
I've added a howto for this - http://directory.fedoraproject.org/wiki/Howto:HostBasedAttributes
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
389-users@lists.fedoraproject.org
-
Colin Panisset -
Ivanov Andrey (M.) -
Rich Megginson