I was looking at the wishlist
(http://directory.fedora.redhat.com/wiki/Wishlist).
Some of these things can already be done, and should be just a matter of
configuration, based on it''s Netscape DS heritage. Wanted to give back
by suggesting some ideas on how to accomplish these wishes where no code
changes are needed.
Under Core Server Features:
1. Disable anonymous binds.
By default, the server creates an annonymous aci in the suffix entry
(i.e. top of the tree).
If you edit that entry and remove that aci, you remove anonymous
access. Note that some
services "require" anonymous access, so may break (some
clients/apps
may need to do anon
access to look up a uid to get a dn to bind as for auth, etc, so it
may either be necessary to
change the config of these clients to bind as something that can
still do these lookups, or
you may have to just tweak anonymous access to limit what it can
see, rather than removing
it altogether).
2. Option to control resource limits specifically for anonymous.
Anonymous uses the default server settings for these resource
limits. I believe Fedora-ds
supports the following attributes on entries: nslookthroughlimit,
nsizelimit, nstimelimit,
and nsidletimeout (these are in the schema, and the Sun and Netscape
servers fds is based
on supports them). If you put these attributes in an entry, when
that entry binds to the server,
these resource limits are used instead of the server defaults. So,
a way to implement control
of resource limits for anonymous is to set the server default
settings to whatever you want
anonymous to have, and then to set these attributes on all users
that you want to be different
(i.e. have more lenient limits) than anonymous. For things like
mail servers, etc, I always
create an entry for the mail/whatever server, and set these
attributes to appropriate values.
FYI: setting any of these to -1 means unlimited.
Under Console Features:
2. Add host based access control to posixAccount/shadowAccount to
determine who can
log into what hosts.
While this is not specifically in Console, it''s relatively
straightforward to add this, if
you''re a little creative :) :
- First, create a new ldap attribute in the schema - lets call it
something like "allowedHosts".
Make sure it is multivalued.
- Second, you need to add it to an objectclass. You could add it to
the PosixAccount
objectclass (simpler, but not recommended because you are
modifying a standard
objectclass), or create a new objectclass (lets call if unixUser,
make it derive from
posixAccount, and add allowedHosts as a required attribute).
- When you create users, set their objectclass to posixAccount and
unixUser (and
shadowAccount). Add a list of hostnames you want the user to log
into in the
allowedHosts field.
- When you configure the Unix/Linux/etc box that the user will log
into:
. if you can define a filter for finding users, set it to
"(&(objectclass=posixAccount)(allowedHosts=<hostname>))"
replacing <hostname> with the hostname of the machine they are
logging into.
. If you cannot define a filter, you can set an IP based aci in
the directory for each
of these hosts that allows them to see only users that can log
into "this" box.
You may have to tweak other aci''s, such as anonymous, so that
they don''t
allow the box to see the users you don''t want seen.
One note to make: purists would say DON''T create attributes and
objectclasses on the fly like this. Personally, I don''t have a problem
creating attributes/objectclasses for my own internal use. But... if
someone wanted to formalize this with "real" registered oids for the
attributes and objectclasses, and/or defining and going through all the
paperwork/review process to do this or expand posixAccount officially, I
would have no objections :). NDS/FDS/SDS are nice in that they allow
you to create these local definitions without all the complexities of
registering those definitions to the rest of the world.
- Jeff
jclowser@unitedmessaging.com wrote:> I was looking at the wishlist > (http://directory.fedora.redhat.com/wiki/Wishlist). > > Some of these things can already be done, and should be just a matter > of configuration, based on it''s Netscape DS heritage. Wanted to give > back by suggesting some ideas on how to accomplish these wishes where > no code changes are needed. > > Under Core Server Features: > 1. Disable anonymous binds. By default, the server creates an > annonymous aci in the suffix entry (i.e. top of the tree). If you > edit that entry and remove that aci, you remove anonymous access. > Note that some > services "require" anonymous access, so may break (some > clients/apps may need to do anon > access to look up a uid to get a dn to bind as for auth, etc, so it > may either be necessary to > change the config of these clients to bind as something that can > still do these lookups, or > you may have to just tweak anonymous access to limit what it can > see, rather than removing > it altogether).Some security conscious sites feel that an anonymous connection shouldn''t even get to the data which is where the access control information is stored. So they want the ability to cut them off early in the BIND request processing.> > 2. Option to control resource limits specifically for anonymous. > Anonymous uses the default server settings for these resource > limits. I believe Fedora-ds > supports the following attributes on entries: nslookthroughlimit, > nsizelimit, nstimelimit, > and nsidletimeout (these are in the schema, and the Sun and > Netscape servers fds is based > on supports them). If you put these attributes in an entry, when > that entry binds to the server, > these resource limits are used instead of the server defaults. So, > a way to implement control > of resource limits for anonymous is to set the server default > settings to whatever you want > anonymous to have, and then to set these attributes on all users > that you want to be different > (i.e. have more lenient limits) than anonymous. For things like > mail servers, etc, I always > create an entry for the mail/whatever server, and set these > attributes to appropriate values. FYI: setting any of these to -1 > means unlimited.Right. But see above.> Under Console Features: > 2. Add host based access control to posixAccount/shadowAccount to > determine who can > log into what hosts. > While this is not specifically in Console, it''s relatively > straightforward to add this, if > you''re a little creative :) : > - First, create a new ldap attribute in the schema - lets call it > something like "allowedHosts". Make sure it is multivalued. > - Second, you need to add it to an objectclass. You could add it > to the PosixAccount > objectclass (simpler, but not recommended because you are > modifying a standard > objectclass), or create a new objectclass (lets call if unixUser, > make it derive from > posixAccount, and add allowedHosts as a required attribute). > - When you create users, set their objectclass to posixAccount and > unixUser (and > shadowAccount). Add a list of hostnames you want the user to > log into in the > allowedHosts field. > - When you configure the Unix/Linux/etc box that the user will log > into: > . if you can define a filter for finding users, set it to > "(&(objectclass=posixAccount)(allowedHosts=<hostname>))" > replacing <hostname> with the hostname of the machine they > are logging into. > . If you cannot define a filter, you can set an IP based aci in > the directory for each > of these hosts that allows them to see only users that can > log into "this" box. > You may have to tweak other aci''s, such as anonymous, so that > they don''t > allow the box to see the users you don''t want seen.I believe most apps use the ''host'' attribute for this, which is defined in the pilot schema. I don''t know if this is a standard. The best thing to do would be to create an AUXILIARY objectclass (e.g. hostAccount?) and have the host attribute as an allowed attribute. Then add that new objectclass to each entry (along with posixAccount and shadowAccount and their required attributes). Does anyone know if there is a standard for host access like this using the ''host'' attribute and, if so, is there a standard objectclass?> One note to make: purists would say DON''T create attributes and > objectclasses on the fly like this. Personally, I don''t have a > problem creating attributes/objectclasses for my own internal use. > But... if someone wanted to formalize this with "real" registered oids > for the attributes and objectclasses, and/or defining and going > through all the paperwork/review process to do this or expand > posixAccount officially, I would have no objections :). NDS/FDS/SDS > are nice in that they allow you to create these local definitions > without all the complexities of registering those definitions to the > rest of the world.Some would say that is a bug in our software :-) But in general, it''s better to use published RFC standards or at least informational RFC''s or Internet-Draft schema.> > - Jeff > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
Richard Megginson wrote:> >> Under Core Server Features: >> 1. Disable anonymous binds. > > ... > Some security conscious sites feel that an anonymous connection > shouldn''t even get to the data which is where the access control > information is stored. So they want the ability to cut them off early > in the BIND request processing.Hmm... If I remove the anonymous aci, and remove all the anonymous aci''s in dse.ldif, what can anonymous see? Doing that seems to restrict anonymous from seeing anything. My guess is that you really need to change it from userdn="ldap:///anyone" (anonymous) to userdn="ldap:///all" (any entry that successfully bound to the server) instead of removig it entirely, or some things will break (i.e. clients that bind can''t see what controls are available, what suffixes exist, etc). I can see wanting the ability to break the connection (or maybe return unwilling to perform) if a client attempts to perform a search or other operation before binding as something other than anonymous (and/or rejecting binds with empty bind dn and bind passwords), but I''m wondering if, with these aci changes, it will generally be "sufficient". Is there anything that is left that anonymous can see?> >> 2. Option to control resource limits specifically for anonymous. > > ... > Right. But see above.Yeah - does modifying dse.ldif sufficiently cover this? I guess is comes down to who''s asking this and why: a. A security expert, who wants to figure out how to 100% tie down everything, or b. An organization that wants to prevent anonymous from skimming their directory for things like email addresses to spam, or uid''s to try to crack, personal info that can be abused in any number of ways, etc. My guess is my suggestion is good enough for b, but maybe not for a(?)> >> Under Console Features: >> 2. Add host based access control to posixAccount/shadowAccount to >> determine who can >> log into what hosts. >> ... > > I believe most apps use the ''host'' attribute for this, which is > defined in the pilot schema. I don''t know if this is a standard. The > best thing to do would be to create an AUXILIARY objectclass (e.g. > hostAccount?) and have the host attribute as an allowed attribute. > Then add that new objectclass to each entry (along with posixAccount > and shadowAccount and their required attributes). Does anyone know if > there is a standard for host access like this using the ''host'' > attribute and, if so, is there a standard objectclass?yeah - I was writing this off the top of my head - there are likely some standard attributes out there that would be better used than what I suggested, but in any case, you''ll have to do something like it to supplement posixAccount and shadowAccount, since these don''t handle that. BTW - what is "standard" schema, other than that it''s in an RFC and/or has an official oid assigned to it? That''s always seemed kinda grey :)>> One note to make: purists would say DON''T create attributes and >> objectclasses on the fly like this. >...> Some would say that is a bug in our software :-) But in general, it''s > better to use published RFC standards or at least informational RFC''s > or Internet-Draft schema.Ya :) And I agree, but it''s a nice thing to be able to do so solve things, esp if it''s just being done as an internal fix like this. Looking briefly at rfc1274, it looks like host is an allowed attribute of account objectclass, so actually, the schema is all already there if you create users that have the account, posixAccount, and shadowAccount objectclasses, so it''s just a matter of being able to configure the client machine to include this in the filter, falling back on aci''s if not (though admittedly, doing this via aci''s gets really ugly really fast, and probably doesn''t scale well - one aci/client host?) - Jeff
jclowser@unitedmessaging.com wrote:> Richard Megginson wrote: > >> >>> Under Core Server Features: >>> 1. Disable anonymous binds. >> >> >> ... >> Some security conscious sites feel that an anonymous connection >> shouldn''t even get to the data which is where the access control >> information is stored. So they want the ability to cut them off >> early in the BIND request processing. > > > Hmm... If I remove the anonymous aci, and remove all the anonymous > aci''s in dse.ldif, what can anonymous see? Doing that seems to > restrict anonymous from seeing anything. My guess is that you really > need to change it from userdn="ldap:///anyone" (anonymous) to > userdn="ldap:///all" (any entry that successfully bound to the server) > instead of removig it entirely, or some things will break (i.e. > clients that bind can''t see what controls are available, what suffixes > exist, etc). > > I can see wanting the ability to break the connection (or maybe return > unwilling to perform) if a client attempts to perform a search or > other operation before binding as something other than anonymous > (and/or rejecting binds with empty bind dn and bind passwords), but > I''m wondering if, with these aci changes, it will generally be > "sufficient". Is there anything that is left that anonymous can see? > >> >>> 2. Option to control resource limits specifically for anonymous. >> >> >> ... >> Right. But see above. > > > Yeah - does modifying dse.ldif sufficiently cover this? I guess is > comes down to who''s asking this and why: > a. A security expert, who wants to figure out how to 100% tie down > everything, or > b. An organization that wants to prevent anonymous from skimming > their directory for things like email addresses to spam, or uid''s to > try to crack, personal info that can be abused in any number of ways, > etc. > > My guess is my suggestion is good enough for b, but maybe not for a(?)Right - a. This applies to the above as well. Anonymous might not be able to "see" anything, but they are allowed to complete the BIND request.> >> >>> Under Console Features: >>> 2. Add host based access control to posixAccount/shadowAccount to >>> determine who can >>> log into what hosts. >>> ... >> >> >> I believe most apps use the ''host'' attribute for this, which is >> defined in the pilot schema. I don''t know if this is a standard. >> The best thing to do would be to create an AUXILIARY objectclass >> (e.g. hostAccount?) and have the host attribute as an allowed >> attribute. Then add that new objectclass to each entry (along with >> posixAccount and shadowAccount and their required attributes). Does >> anyone know if there is a standard for host access like this using >> the ''host'' attribute and, if so, is there a standard objectclass? > > > yeah - I was writing this off the top of my head - there are likely > some standard attributes out there that would be better used than what > I suggested, but in any case, you''ll have to do something like it to > supplement posixAccount and shadowAccount, since these don''t handle > that. BTW - what is "standard" schema, other than that it''s in an RFC > and/or has an official oid assigned to it? That''s always seemed kinda > grey :)That''s usually what is meant.> >>> One note to make: purists would say DON''T create attributes and >>> objectclasses on the fly like this. >> >> > ... > >> Some would say that is a bug in our software :-) But in general, >> it''s better to use published RFC standards or at least informational >> RFC''s or Internet-Draft schema. > > > Ya :) And I agree, but it''s a nice thing to be able to do so solve > things, esp if it''s just being done as an internal fix like this. > Looking briefly at rfc1274, it looks like host is an allowed attribute > of account objectclass, so actually, the schema is all already there > if you create users that have the account, posixAccount, and > shadowAccount objectclasses, so it''s just a matter of being able to > configure the client machine to include this in the filter, falling > back on aci''s if not (though admittedly, doing this via aci''s gets > really ugly really fast, and probably doesn''t scale well - one > aci/client host?)Unfortunately, the objectclass "account" is a structural objectclass, which means you can''t "mix it in" with other structural objectclasses such as inetOrgPerson. So I think either the standard needs to be revised to make account auxiliary, or create a new objectclass (auxAccount?).> > - Jeff > > -- > Fedora-directory-users mailing list > Fedora-directory-users@redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users
Rich Megginson wrote:> Unfortunately, the objectclass "account" is a structural objectclass, > which means you can''t "mix it in" with other structural objectclasses > such as inetOrgPerson. So I think either the standard needs to be > revised to make account auxiliary, or create a new objectclass > (auxAccount?).What keeps you from doing this (I ask because I''ve mixed these before, and nothing "bad" happened)? Where is that restriction defined? (I feel kinda stupid if I''ve been doing this for all these years and in all that time it hasn''t been "allowed" :) ) - Jeff
jclowser@unitedmessaging.com wrote:> Rich Megginson wrote: > >> Unfortunately, the objectclass "account" is a structural objectclass, >> which means you can''t "mix it in" with other structural objectclasses >> such as inetOrgPerson. So I think either the standard needs to be >> revised to make account auxiliary, or create a new objectclass >> (auxAccount?). > > > What keeps you from doing this (I ask because I''ve mixed these before, > and nothing "bad" happened)? Where is that restriction defined? (I > feel kinda stupid if I''ve been doing this for all these years and in all > that time it hasn''t been "allowed" :) )Well, for example if you like to somehow integrate with OpenLDAP, recent versions, 2.1 and higher iirc, enforce structural integrity and do not allow the administrator to disable it. IMO, structural integrity should be observed, but the administrator should have the chance to turn it off, just like schema checking. To that end, I would like to see FDS enable structural integrity checking by default, with an on-off toggle. -- Mike
Sorry to dredge up a really old thread, but I''ve been trying to track
down something about it that''s been bothering me.
Basically, part of the thread devolved to the idea of creating a single
user entry that has objectclasses: inetorgperson, account,
posixaccount, shadowaccount, etc. If I understand the response (see
below), this violates ldap standards because you are mixing in
structural objectclasses and that is not allowed(?)
It was something I hadn''t known before, so finally got around to
looking
for where that was defined.
Looking at RFC 2251:
Each entry MUST have an objectClass attribute. The objectClass
attribute specifies the object classes of an entry, which along with
the system and user schema determine the permitted attributes of an
entry. Values of this attribute may be modified by clients, but the
objectClass attribute cannot be removed. Servers may restrict the
modifications of this attribute to prevent the basic structural class
of the entry from being changed (e.g. one cannot change a person into
a country). When creating an entry or adding an objectClass value to
an entry, all superclasses of the named classes are implicitly added
as well if not already present, and the client must supply values for
any mandatory attributes of new superclasses.
Looking at rfc 2252:
The format for representation of object classes is defined in X.501
[3]. In general every entry will contain an abstract class ("top" or
"alias"), at least one structural object class, and zero or more
auxiliary object classes. Whether an object class is abstract,
structural or auxiliary is defined when the object class identifier
is assigned. An object class definition should not be changed
without having a new identifier assigned to it.
This is all I could find that came close - rfc2251 seems to say servers
may disallow changing structural objectclasses on an entry (to prevent
changing a user to a country, for example). RFC 2252 actually seems to
specifically say you _can_ mix structural objectclasses in one entry.
Did I misunderstand something? If this is actually illegal, does anyone
know a reference that documents this? Or am I just completely confused
here?
- Jeff
>> Looking briefly at rfc1274, it looks like host is an allowed
>> attribute of account objectclass, so actually, the schema is all
>> already there if you create users that have the account,
>> posixAccount, and shadowAccount objectclasses, ...
>
> Unfortunately, the objectclass "account" is a structural
objectclass,
> which means you can''t "mix it in" with other structural
objectclasses
> such as inetOrgPerson. So I think either the standard needs to be
> revised to make account auxiliary, or create a new objectclass
> (auxAccount?).
That''s a very good question. The "one structural
objectclass" rule
probably comes from X.500. Can you post this same question to the
ldap@umich.edu list? There are many people there who are knowledgeable
about the roots of LDAP and X.500 who would probably be able to answer
your question.
I believe this is going to become more and more of a problem with LDAP
in general - how to create entries that belong to many different
objectclasses, if more than one of them are structural? It''s almost as
if you need an analogous auxiliary objectclass for each structural one.
I''ve encountered this problem before in Java programming, and I used
the
following paradigm: create pairs of interface/implementation class.
Start with the interface e.g.
public interface IDoer {
public String getProp1();
public String getProp2();
...
}
Then, create the implementation class:
public class DoerImpl implements IDoer {
...
}
This idea could be extended to LDAP (albeit clumsily perhaps) e.g.
objectclass auxInetOrgPerson SUP ''inetOrgPerson'' AUXILIARY
to "extend" the structural inetOrgPerson class into an
"interface" that
could be mixed in with another structural objectclass. I don''t know if
this is possible or allowed by LDAP or X.500. It would probably have
been better to do the obverse e.g. create auxInetOrgPerson first as an
AUXILIARY class with all of the attributes, then create inetOrgPerson
SUP ''auxInetOrgPerson'' STRUCTURAL. But then you would have to
do that
with all of the superclasses as well: organizationalPerson and person.
Jeff Clowser wrote:
> Sorry to dredge up a really old thread, but I''ve been trying to
track
> down something about it that''s been bothering me.
>
> Basically, part of the thread devolved to the idea of creating a
> single user entry that has objectclasses: inetorgperson, account,
> posixaccount, shadowaccount, etc. If I understand the response (see
> below), this violates ldap standards because you are mixing in
> structural objectclasses and that is not allowed(?)
>
> It was something I hadn''t known before, so finally got around to
> looking for where that was defined.
>
> Looking at RFC 2251:
>
> Each entry MUST have an objectClass attribute. The objectClass
> attribute specifies the object classes of an entry, which along with
> the system and user schema determine the permitted attributes of an
> entry. Values of this attribute may be modified by clients, but the
> objectClass attribute cannot be removed. Servers may restrict the
> modifications of this attribute to prevent the basic structural class
> of the entry from being changed (e.g. one cannot change a person into
> a country). When creating an entry or adding an objectClass value to
> an entry, all superclasses of the named classes are implicitly added
> as well if not already present, and the client must supply values for
> any mandatory attributes of new superclasses.
>
> Looking at rfc 2252:
>
> The format for representation of object classes is defined in X.501
> [3]. In general every entry will contain an abstract class ("top"
or
> "alias"), at least one structural object class, and zero or more
> auxiliary object classes. Whether an object class is abstract,
> structural or auxiliary is defined when the object class identifier
> is assigned. An object class definition should not be changed
> without having a new identifier assigned to it.
>
>
> This is all I could find that came close - rfc2251 seems to say
> servers may disallow changing structural objectclasses on an entry (to
> prevent changing a user to a country, for example). RFC 2252 actually
> seems to specifically say you _can_ mix structural objectclasses in
> one entry.
>
> Did I misunderstand something? If this is actually illegal, does
> anyone know a reference that documents this? Or am I just completely
> confused here?
>
> - Jeff
>
>>> Looking briefly at rfc1274, it looks like host is an allowed
>>> attribute of account objectclass, so actually, the schema is all
>>> already there if you create users that have the account,
>>> posixAccount, and shadowAccount objectclasses, ...
>>
>>
>> Unfortunately, the objectclass "account" is a structural
objectclass,
>> which means you can''t "mix it in" with other
structural objectclasses
>> such as inetOrgPerson. So I think either the standard needs to be
>> revised to make account auxiliary, or create a new objectclass
>> (auxAccount?).
>
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users