[Fedora-directory-users] Wishlist

[Richard Megginson]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20050610/d1850530/attachment.bin>