[Fedora-directory-users] Wishlist

[jclowser at unitedmessaging.com]

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