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://lists.fedoraproject.org/pipermail/389-users/attachments/20050613/5bf7235d/attachment.bin
