[Fedora-directory-users] Wishlist

[Rich Megginson]

jclowser at 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 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/20050613/5bf7235d/attachment.bin>