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
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
