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