jclowser(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users