[Fedora-directory-users] Wishlist

[jclowser at unitedmessaging.com]

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