LDAP: selective accounts on hosts
David Magda
The traditional way of selectively allowing only certain users on
particular hosts with NIS is to use either netgroups or the user's
primary group through entries in passwd(4):
...
+@admins:::::::/some/shell
+:::::::/bin/false
The same thing can be done if the LDAP is the back-end store.
I'm curious as to whether there is a more "advanced" technique with
LDAP (specifically under Solaris 8). Can I add something to the LDAP
records that says 'this account is only valid / visible on host(s) X,
Y, and Z'? Ideally this would also work for utilities like
ldapaddent(1M) as well.
The LDAP master and slave servers would be OpenLDAP 2.2.x.
Thanks for any info.
--
David Magda <dmagda at ee.ryerson.ca>, http://www.magda.ca/
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Gary Tay Teng Teck
> Hello,
>
> The traditional way of selectively allowing only certain users on
> particular hosts with NIS is to use either netgroups or the user's
> primary group through entries in passwd(4):
>
> ...
> +@admins:::::::/some/shell
> +:::::::/bin/false
>
> The same thing can be done if the LDAP is the back-end store.
>
> I'm curious as to whether there is a more "advanced" technique with
> LDAP (specifically under Solaris 8). Can I add something to the LDAP
> records that says 'this account is only valid / visible on host(s) X,
> Y, and Z'? Ideally this would also work for utilities like
> ldapaddent(1M) as well.
>
> The LDAP master and slave servers would be OpenLDAP 2.2.x.
>
> Thanks for any info.
>
Just a comment: if you use OpenLDAP as servers, it is better to use
OpenLDAP as clients (I had tried SUN native LDAP client works as well,
but doubt that will remain in future Solaris releases/patches), but then
you are banking on OpenSource support and facing the massive efforts to
deploy (install/configure) OpenLDAP clients. SUN iDS5 and SUN native
LDAP client (built-in) may be a better choice.
There is a latest discovery w.r.t. "NetGroup" by Diego worth reading:
http://lists.fini.net/pipermail/ldap-interop/2005-January/000211.html
As netgroup does not work well with OpenLDAP, some people has reported
another mean that works: by using the "host" attribute in People
entries, and specifying "check host attribute" in PAM_LDAP's
/etc/ldap.conf. You may need to add the schema and objectclass
(account?) that provide this attribute. This works well if the # of
hosts or # of users is limited.
host: host1.domain.com
host: host2.domain.com
Pls search Google for "netgroup site:www.openldap.org", I think there
are some other tricks people play to the default search filter for
People branch.
You may also find these articles informative:
http://www.samag.com/documents/s=9142/sam0405a/0405a.htm
http://netmojo.ca/howto/solaris-openldap.html
I also heard from PAM mail list there is a something like
"pam_listusers" module (not sure the spelling) that could restrict
authenticated users list on a per host basis.
Rgds
Gary
ne...@elaan.dds.nl
> Hello,
>
> The traditional way of selectively allowing only certain users on
> particular hosts with NIS is to use either netgroups or the user's
> primary group through entries in passwd(4):
>
> ...
> +@admins:::::::/some/shell
> +:::::::/bin/false
>
> The same thing can be done if the LDAP is the back-end store.
>
> I'm curious as to whether there is a more "advanced" technique with
> LDAP (specifically under Solaris 8). Can I add something to the LDAP
> records that says 'this account is only valid / visible on host(s) X,
> Y, and Z'? Ideally this would also work for utilities like
> ldapaddent(1M) as well.
>
> The LDAP master and slave servers would be OpenLDAP 2.2.x.
In my environment every LDAP client (Solaris 8, AIX 4.3.3 and
5.2) has it's own directory user to read the users from the
LDAP-directory. These proxy-agent users can be put into LDAP
groups. Every user's entry in ou=People can have one of 2
specially made attributes, both multivalued and containing
a DN. One mentions the DN('s) of the system('s) this user
can login to, the other mentions the DN('s) of the system-
group('s) this user can login to. This is all made possible
with one ACI that allows read, search, compare access to
the person entries in ou=People when the DN of the system
requesting the access is either mentioned in attribute1 or
is in a group mentioned in attribute2. I don't know if
it is possible to make these kind of ACI's in OpenLDAP,
I use SunONE Directory server (5.2).
HTH, Erik.
David Magda
> is in a group mentioned in attribute2. I don't know if it is
> possible to make these kind of ACI's in OpenLDAP, I use SunONE
> Directory server (5.2).
ACI is marked as "experimental" in OpenLDAP's autoconf script.
I wouldn't mind using DS, but for the 18 servers and 50+ accounts I
don't know whether it's worth it. NIS was rejected out-right for
reasons which aren't exactly clear with me (besides the obvious
'ypcat passwd' issue).
David Magda
> efforts to deploy (install/configure) OpenLDAP clients. SUN iDS5
> and SUN native LDAP client (built-in) may be a better choice.
iDS5 is commercial software, correct?
> As netgroup does not work well with OpenLDAP, some people has
> reported another mean that works: by using the "host" attribute in
> People entries, and specifying "check host attribute" in PAM_LDAP's
> /etc/ldap.conf. You may need to add the schema and objectclass
> (account?) that provide this attribute. This works well if the # of
> hosts or # of users is limited.
Not having a 'flat' authorization space is the main complication. I'm
currently working under the assumption that it is preferable to
continue to have only certain users allowed on certain hosts (or
classes of hosts: "application", database, QA, and development
hosts). If I can simply have all accounts everywhere things are much
simpler.
Also, I'm planning to have one master and one (maybe two) slave
servers for availability. Would it also be possible to have have the
accounts also in the passwd(4) file "just in case" in addition to
LDAP? Or is that level of "availability paranoia" generally not worth
the effort if there are multiple LDAP servers available? (We
currently have all home directories on one NFS server with no
secondary server.) I would probably use 'ldapaddent -d' to dump to
flat files. Mostly passwd(4), shadow(4), and groups(4).
Thanks for all the help (now and in the past (and probably in the
future :)).
Gary Tay Teng Teck
> Gary Tay Teng Teck <gar...@singnet.com.sg> writes:
>
>
>>efforts to deploy (install/configure) OpenLDAP clients. SUN iDS5
>>and SUN native LDAP client (built-in) may be a better choice.
>
>
> iDS5 is commercial software, correct?
>
>
Not exactly.
iDS5.1 is built-into Solaris9, I am not sure if it is so with the NEW
"Conditional-Free" Solaris10 (does it come with iDS5.1 or iDS5.2? anyone
pls let us know).
iDS5.2 could be downloaded from SUN download site. I heard that someone
said it has a limitation of 200,000 entries, if anyone or someone from
SUN could say if it is true or false, it would be helpfull.
Gary
Neal A. Lucier
My understanding from having a "lunch and learn" with our Sun rep last
week was that the iDS5.1 and iDS5.2 were both free if you had less than
250,000 users (possibly he meant 250,000 entries, but he said users).
As far as I know there are no limitations in the software you download
for free, just that you are supposed to start giving Sun money after you
have 250k users.
--
Neal Lucier
nlu...@math.purdue.edu
Bruno Saverio Delbono
> iDS5.2 could be downloaded from SUN download site. I heard that someone
> said it has a limitation of 200,000 entries, if anyone or someone from
> SUN could say if it is true or false, it would be helpfull.
Other than paper licensing, this doesn't apply. IIRC, you can have up to
200,000 entries without having to buy any licenses. Once over 200,000
you may have to buy additional licenses for your users.
Other than that, there is no inherent forced limit on the no. of
entries. I've successfully tested it with over 1 million entries with no
problems.
-Bruno
Neal A. Lucier
Erik,
This is the best solution I have seen so far to this problem. Could you
post a representative ACI that is doing this.
I have managed to disable the ACI that allows the Solaris client to see
the crypt passwords when using pam_unix, but that is about the extent of
my ACI knowledge, and any samples or help would be greatly appreciated.
There is another not so pretty solution where in nsswitch.conf you set:
passwd compat
and then you can use the +@netgroup syntax in the /etc/passwd file.
--
Neal Lucier
nlu...@math.purdue.edu
David Magda
> There is another not so pretty solution where in nsswitch.conf you
> set:
>
> passwd compat
>
> and then you can use the +@netgroup syntax in the /etc/passwd file.
From nsswitch.conf(4):
passswd: compat
passwd_compat: ldap
The same thing could be done for groups:
group: compat
group_compat: ldap
ne...@elaan.dds.nl
> ne...@elaan.dds.nl wrote:
>> David Magda <dmagda+tr...@ee.ryerson.ca> wrote:
>>>I'm curious as to whether there is a more "advanced" technique with
>>>LDAP (specifically under Solaris 8). Can I add something to the LDAP
>>>records that says 'this account is only valid / visible on host(s) X,
>>>Y, and Z'? Ideally this would also work for utilities like
>>>ldapaddent(1M) as well.
>>>
>>>The LDAP master and slave servers would be OpenLDAP 2.2.x.
>>
>> In my environment every LDAP client (Solaris 8, AIX 4.3.3 and
>> 5.2) has it's own directory user to read the users from the
>> LDAP-directory. These proxy-agent users can be put into LDAP
>> groups. Every user's entry in ou=People can have one of 2
>> specially made attributes, both multivalued and containing
>> a DN. One mentions the DN('s) of the system('s) this user
>> can login to, the other mentions the DN('s) of the system-
>> group('s) this user can login to. This is all made possible
>> with one ACI that allows read, search, compare access to
>> the person entries in ou=People when the DN of the system
>> requesting the access is either mentioned in attribute1 or
>> is in a group mentioned in attribute2. I don't know if
>> it is possible to make these kind of ACI's in OpenLDAP,
>> I use SunONE Directory server (5.2).
>>
>
> Erik,
> This is the best solution I have seen so far to this problem. Could you
> post a representative ACI that is doing this.
Nice you like it. I will post the ACI, but you'll have to wait
a few days as the ACI is at work and I'm not...
We use this to allow about 80 or so different groups of people
on 80 set's of machine's selected from about 340. Some of the
system-groups are even dynamic LDAP groups (objectclass =
groupOfURLs) selecting the "membermachine's" on certain attributes
in the system's proxy-agent user, like the machine's name.
Because the have the machine-naming standard it's easy to
distinguish SUN's from AIX'en, and use these dynamic groups to
let the SUN systemmanagement people login to SUN's only v.v.
Erik.
ne...@elaan.dds.nl
> Gary Tay Teng Teck <gar...@singnet.com.sg> writes:
>
>> efforts to deploy (install/configure) OpenLDAP clients. SUN iDS5
>> and SUN native LDAP client (built-in) may be a better choice.
>
> iDS5 is commercial software, correct?
As far as I know it's free to use for upto 200k entries. Please the
with you Sun sales rep.
>> As netgroup does not work well with OpenLDAP, some people has
>> reported another mean that works: by using the "host" attribute in
>> People entries, and specifying "check host attribute" in PAM_LDAP's
>> /etc/ldap.conf. You may need to add the schema and objectclass
>> (account?) that provide this attribute. This works well if the # of
>> hosts or # of users is limited.
>
> Also, I'm planning to have one master and one (maybe two) slave
> servers for availability. Would it also be possible to have have the
> accounts also in the passwd(4) file "just in case" in addition to
> LDAP? Or is that level of "availability paranoia" generally not worth
> the effort if there are multiple LDAP servers available? (We
> currently have all home directories on one NFS server with no
> secondary server.) I would probably use 'ldapaddent -d' to dump to
> flat files. Mostly passwd(4), shadow(4), and groups(4).
Are you using Sol8 of Sol9? Please note that with the Native LDAP Phase
II backport from 9 to 8 certain restrictions where introduced that have
some consequences, especially where using LDAPS (server-certificate)
to encrypt the traffic (which is the main reason the backport was
requested by so many customers AFAIK). When using LDAPS, the Solaris 8
Native LDAP Phase II client (pathc 108993-25 or higher) ...
1) ... can only have it's server at ports 389/636.
2) ... does not comprehend password-expiry warnings given
by SunONE Directory Server.
3) ... does not let you in when the directory server says
the password has expired (telnet), of when you are given a warning
(SSH, at least the F-Secure SSH we use).
Because of these last two you'll have to do some scripting (e.g.
in /etc/profile) to retreive the password-expiration time with an
ldapsearch, and warn/force the user to change the password.
4) ... is panicky about being referred to another server for
updates (think updating you password) and getting secure-referrals.
It will reject valid referral-URLs to the master with the message
"Invalid URL" in syslog, just because there is a portnumber in it,
even if the port-number is 636. This makes it impossible to update
your password on Solaris systems connected to a replica.
Because of this we use SunONE Directory Server 5.2 and have 4
masters: 2 in each of our 2 datacentre's.
HTH, Erik
ne...@elaan.dds.nl
Hi,
Here we go. Needed to work today (sunday), and this is the SunONE
Directory Server ACI's doing the work described above:
For straight rfc2307 clients (Native Solaris 8+), read-access to
user-attributes:
(targetattr = "objectClass || uid || uidNumber || gidNumber ||
gecos || description || homeDirectory || loginshell ||
shadowLastChange || shadowMin || shadowMax || shadowWarning ||
shadowInactive || shadowExpire || shadowFlag")
(version 3.0;acl "Allow users on system(s) by systemname or
system-group";allow (read,compare,search)(userattr =
"myOrgUnixSystem#USERDN" or userattr =
"myOrgUnixSystemGroup#GROUPDN");)
In human language this translates to:
- When access is requested to the attributes "Objectclass, uid,
uidNumber, etc ,shadowExpire or shadowFlag" ....
- Allow it when read, search and compare access is requested by ...
- a LDAP-user whose USER-DN is in the myOrgUnixSystem attribute ...
or
- a LDAP-user who is in a group whose GROUP-DN is in the
myOrgUnixSystemGroup attribute.
Please note that the proxy-agent users used by Solaris systems
don't need read access to the userPassword attribute! This is
because the Native Solaris LDAP client code verifies the users
password by doing a LDAP bind to the directory with the DN
of the user's entry, and the password given by the user. In
SunONE Directory Server you don't have to give a user any rights
to the userPassword attribute to be able to bind.
When using AIX 5.2 clients with the rfc2307bis + AIX extensions
schema you'll have to add access to quite some more attributes
for AIX systems only. This looks like this in SunONE Directory
Server:
(targetattr = "admingroupnames || aixdefaultmaclevel || aixfuncmode ||
aixisdceexport || aixlowmaclevel || aixpromptmac || aixscreens ||
aixuppermaclevel || auditclasses || authmethod1 || authmethod2 ||
coresizelimit || coresizelimithard || cpusize || cpusizehard ||
datasegsize || datasegsizehard || filepermmask || filesizelimit ||
filesizelimithard || grouplist || groupswitchuserallowed ||
hostlastlogin || hostlastunsuccessfullogin || isaccountenabled ||
isadministrator || isdaemon || isloginallowed || isremoteaccessallowed
|| isswitchuserallowed || ixlastupdate || ixtimelastlogin ||
ixtimelastunsuccessfullogin || logintimes || maxfailedlogins || maxlogin
|| openfilelimit || openfilelimithard || passwordchar ||
passwordcheckmethods || passworddictfiles || passwordexpiretime ||
passwordflags || passwordhistsize || passwordmaxrepeatedchars ||
passwordminalphachars || passwordmindiffchars || passwordminlength ||
passwordminotherchars || physicalmemlimit || physicalmemlimithard ||
rolelist || stacksizelimit || stacksizelimithard || systemenvironment ||
terminalaccess || terminallastlogin || terminallastunsuccessfullogin ||
timeexpiredlogout || timeexpirelockout || trustedpathstatus ||
unsuccessfullogincount || username || userenvironment || userPassword")
(version 3.0;acl "Allow users on AIX-system(s) by systemname
or system-group";allow (read,compare,search)(groupdn = "ldap:///cn=Hosts
with AIX,ou=Hostgroups,ou=Unix,ou=Services,ou=Groups,o=myOrg" and (userattr =
"myOrgUnixSystem#USERDN" or userattr =
"myOrgUnixSystemGroup#GROUPDN");)
As you can see AIX needs read access to the userPassword attribute. This
is because AIX does the comparison of the excrypted password from the
LDAP-directory and the password the user just typed on the AIX system
itself. AIX also need to write some attributes. These attributes
store the hosti, time and terminal of the last (un)successfull login and
the unsuccessfull logincount:
(targetattr = "hostlastlogin || hostlastunsuccessfullogin ||
ixlastupdate || ixtimelastlogin || ixtimelastunsuccessfullogin ||
terminallastlogin || terminallastunsuccessfullogin ||
unsuccessfullogincount") (version 3.0;acl "Allow users on AIX-system(s)
by systemname or system-group";allow (write)(groupdn = "ldap:///cn=Hosts
with AIX,ou=Hostgroups,ou=Unix,ou=Services,ou=Groups,o=myOrg" and (userattr =
"myOrgUnixSystem#USERDN" or userattr =
"myOrgUnixSystemGroup#GROUPDN");)
As you see we don't allow AIX systems to update the userPassword attribute.
This means you cannot change your LDAP password from an AIX machine. This
has 2 reasons:
1) To enable this you would need to give write access to the
userPassword attribute of all users, to the LDAP-proxy-agent users of
AIX systems.
2) The password of these LDAP-proxy-agent users is not encrypted
on AIX, but it is in /etc/security/ldap/ldap.cfg. This file is permission
600 for root, but still I think this is quite a risk. Especially when
compared to Solaris. On Solaris, when you update the password, the Solaris
LDAP proxy-agent user does some LDAP-queries to find the DN of the entry
belonging to the Unix user trying to change his/her password, and subse-
quently uses the old password to bind to the LDAP-directory server as
the entry belonging to the Unix user. It then proceeds to write the
new password in the userPassword attribute. This way only the user
him/herself needs write access to the userPassword attribute of his/her
own entry. This can be allowed with standard ACI's.
BTW: In AIX 5.3 you can configure your AIX machine to use this type of
password checking/changing behaviour. It's called ldap_auth, and the
old type has been branded "unix_auth". We had requested this, and
maybe others did too.
If people want/need to translate these ACI's to OpenLDAP, I'd like
to request them to post the result, as I may be using it in my
(Open)LDAP server at home.
HTH, Erik.
P.S. Sorry, it's quite a long post, and may not always be within
80 columns.
Gary Tay Teng Teck
Erik, I suggest you could post your trick to comp.unix.aix also.
Gary
David Magda
> As far as I know it's free to use for upto 200k entries. Please the
> with you Sun sales rep.
I think we'll be well under that limit, but I'll double check on
details. Thanks.
> Are you using Sol8 of Sol9? Please note that with the Native LDAP
> Phase II backport from 9 to 8 certain restrictions where introduced
> that have some consequences, especially where using LDAPS
Solaris 8 now, but we may be migrating this year to something
else. It hasn't been decied on whether we'll be going to 9 or 10
(when it comes out).
I personally don't see the need to change given what we're doing, but
I'm the low man on the totem pole. :>
> (server-certificate) to encrypt the traffic (which is the main
> reason the backport was requested by so many customers AFAIK). When
> using LDAPS, the Solaris 8 Native LDAP Phase II client (pathc
We will probably not be using LPAPS: we have about two dozen hosts,
on a small number switches (< 5), on just one subnet (/24) in a
fairly secluded network. I don't think it's necessary for LDAPS if we
implement ACLs on the userPassword field.
> Because of these last two you'll have to do some scripting (e.g.
> in /etc/profile) to retreive the password-expiration time with an
> ldapsearch, and warn/force the user to change the password.
I'll keep that in mind.
> even if the port-number is 636. This makes it impossible to update
> your password on Solaris systems connected to a replica. Because
> of this we use SunONE Directory Server 5.2 and have 4 masters: 2 in
> each of our 2 datacentre's.
If I stick with OpenLDAP, I'll probably be going with one master and
four slaves: the master and two slaves at our primary site, and one
slave in each of our off-site locations.