FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 05-31-2011, 07:30 AM
Colin Panisset
 
Default Views, Filtered roles and CoS

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.
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-31-2011, 01:59 PM
Rich Megginson
 
Default 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
 
Old 05-31-2011, 03:45 PM
Andrey Ivanov
 
Default 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

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


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 05-31-2011, 10:50 PM
Colin Panisset
 
Default 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
 
Old 10-06-2011, 03:23 PM
Rich Megginson
 
Default 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) :

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>


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
 

Thread Tools




All times are GMT. The time now is 09:38 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org