I was looking at the wishlist (http://directory.fedora.redhat.com/wiki/Wishlist).
Some of these things can already be done, and should be just a matter of configuration, based on it's Netscape DS heritage. Wanted to give back by suggesting some ideas on how to accomplish these wishes where no code changes are needed.
Under Core Server Features: 1. Disable anonymous binds. By default, the server creates an annonymous aci in the suffix entry (i.e. top of the tree). If you edit that entry and remove that aci, you remove anonymous access. Note that some services "require" anonymous access, so may break (some clients/apps may need to do anon access to look up a uid to get a dn to bind as for auth, etc, so it may either be necessary to change the config of these clients to bind as something that can still do these lookups, or you may have to just tweak anonymous access to limit what it can see, rather than removing it altogether).
2. Option to control resource limits specifically for anonymous. Anonymous uses the default server settings for these resource limits. I believe Fedora-ds supports the following attributes on entries: nslookthroughlimit, nsizelimit, nstimelimit, and nsidletimeout (these are in the schema, and the Sun and Netscape servers fds is based on supports them). If you put these attributes in an entry, when that entry binds to the server, these resource limits are used instead of the server defaults. So, a way to implement control of resource limits for anonymous is to set the server default settings to whatever you want anonymous to have, and then to set these attributes on all users that you want to be different (i.e. have more lenient limits) than anonymous. For things like mail servers, etc, I always create an entry for the mail/whatever server, and set these attributes to appropriate values. FYI: setting any of these to -1 means unlimited.
Under Console Features: 2. Add host based access control to posixAccount/shadowAccount to determine who can log into what hosts. While this is not specifically in Console, it's relatively straightforward to add this, if you're a little creative :) : - First, create a new ldap attribute in the schema - lets call it something like "allowedHosts". Make sure it is multivalued. - Second, you need to add it to an objectclass. You could add it to the PosixAccount objectclass (simpler, but not recommended because you are modifying a standard objectclass), or create a new objectclass (lets call if unixUser, make it derive from posixAccount, and add allowedHosts as a required attribute). - When you create users, set their objectclass to posixAccount and unixUser (and shadowAccount). Add a list of hostnames you want the user to log into in the allowedHosts field. - When you configure the Unix/Linux/etc box that the user will log into: . if you can define a filter for finding users, set it to "(&(objectclass=posixAccount)(allowedHosts=<hostname>))" replacing <hostname> with the hostname of the machine they are logging into. . If you cannot define a filter, you can set an IP based aci in the directory for each of these hosts that allows them to see only users that can log into "this" box. You may have to tweak other aci's, such as anonymous, so that they don't allow the box to see the users you don't want seen.
One note to make: purists would say DON'T create attributes and objectclasses on the fly like this. Personally, I don't have a problem creating attributes/objectclasses for my own internal use. But... if someone wanted to formalize this with "real" registered oids for the attributes and objectclasses, and/or defining and going through all the paperwork/review process to do this or expand posixAccount officially, I would have no objections :). NDS/FDS/SDS are nice in that they allow you to create these local definitions without all the complexities of registering those definitions to the rest of the world.
- Jeff
jclowser@unitedmessaging.com wrote:
I was looking at the wishlist (http://directory.fedora.redhat.com/wiki/Wishlist).
Some of these things can already be done, and should be just a matter of configuration, based on it's Netscape DS heritage. Wanted to give back by suggesting some ideas on how to accomplish these wishes where no code changes are needed.
Under Core Server Features:
- Disable anonymous binds. By default, the server creates an
annonymous aci in the suffix entry (i.e. top of the tree). If you edit that entry and remove that aci, you remove anonymous access. Note that some services "require" anonymous access, so may break (some clients/apps may need to do anon access to look up a uid to get a dn to bind as for auth, etc, so it may either be necessary to change the config of these clients to bind as something that can still do these lookups, or you may have to just tweak anonymous access to limit what it can see, rather than removing it altogether).
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.
- Option to control resource limits specifically for anonymous. Anonymous uses the default server settings for these resource
limits. I believe Fedora-ds supports the following attributes on entries: nslookthroughlimit, nsizelimit, nstimelimit, and nsidletimeout (these are in the schema, and the Sun and Netscape servers fds is based on supports them). If you put these attributes in an entry, when that entry binds to the server, these resource limits are used instead of the server defaults. So, a way to implement control of resource limits for anonymous is to set the server default settings to whatever you want anonymous to have, and then to set these attributes on all users that you want to be different (i.e. have more lenient limits) than anonymous. For things like mail servers, etc, I always create an entry for the mail/whatever server, and set these attributes to appropriate values. FYI: setting any of these to -1 means unlimited.
Right. But see above.
Under Console Features: 2. Add host based access control to posixAccount/shadowAccount to determine who can log into what hosts. While this is not specifically in Console, it's relatively straightforward to add this, if you're a little creative :) :
- First, create a new ldap attribute in the schema - lets call it
something like "allowedHosts". Make sure it is multivalued.
- Second, you need to add it to an objectclass. You could add it
to the PosixAccount objectclass (simpler, but not recommended because you are modifying a standard objectclass), or create a new objectclass (lets call if unixUser, make it derive from posixAccount, and add allowedHosts as a required attribute).
- When you create users, set their objectclass to posixAccount and
unixUser (and shadowAccount). Add a list of hostnames you want the user to log into in the allowedHosts field.
- When you configure the Unix/Linux/etc box that the user will log
into: . if you can define a filter for finding users, set it to "(&(objectclass=posixAccount)(allowedHosts=<hostname>))" replacing <hostname> with the hostname of the machine they are logging into. . If you cannot define a filter, you can set an IP based aci in the directory for each of these hosts that allows them to see only users that can log into "this" box. You may have to tweak other aci's, such as anonymous, so that they don't allow the box to see the users you don't want seen.
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?
One note to make: purists would say DON'T create attributes and objectclasses on the fly like this. Personally, I don't have a problem creating attributes/objectclasses for my own internal use. But... if someone wanted to formalize this with "real" registered oids for the attributes and objectclasses, and/or defining and going through all the paperwork/review process to do this or expand posixAccount officially, I would have no objections :). NDS/FDS/SDS are nice in that they allow you to create these local definitions without all the complexities of registering those definitions to the rest of the world.
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.
- Jeff
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Richard Megginson wrote:
Under Core Server Features:
- 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?
- 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
jclowser@unitedmessaging.com wrote:
Richard Megginson wrote:
Under Core Server Features:
- 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?
- 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Rich Megginson wrote:
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?).
What keeps you from doing this (I ask because I've mixed these before, and nothing "bad" happened)? Where is that restriction defined? (I feel kinda stupid if I've been doing this for all these years and in all that time it hasn't been "allowed" :) )
- Jeff
jclowser@unitedmessaging.com wrote:
Rich Megginson wrote:
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?).
What keeps you from doing this (I ask because I've mixed these before, and nothing "bad" happened)? Where is that restriction defined? (I feel kinda stupid if I've been doing this for all these years and in all that time it hasn't been "allowed" :) )
Well, for example if you like to somehow integrate with OpenLDAP, recent versions, 2.1 and higher iirc, enforce structural integrity and do not allow the administrator to disable it.
IMO, structural integrity should be observed, but the administrator should have the chance to turn it off, just like schema checking.
To that end, I would like to see FDS enable structural integrity checking by default, with an on-off toggle.
-- Mike
Sorry to dredge up a really old thread, but I've been trying to track down something about it that's been bothering me.
Basically, part of the thread devolved to the idea of creating a single user entry that has objectclasses: inetorgperson, account, posixaccount, shadowaccount, etc. If I understand the response (see below), this violates ldap standards because you are mixing in structural objectclasses and that is not allowed(?)
It was something I hadn't known before, so finally got around to looking for where that was defined.
Looking at RFC 2251:
Each entry MUST have an objectClass attribute. The objectClass attribute specifies the object classes of an entry, which along with the system and user schema determine the permitted attributes of an entry. Values of this attribute may be modified by clients, but the objectClass attribute cannot be removed. Servers may restrict the modifications of this attribute to prevent the basic structural class of the entry from being changed (e.g. one cannot change a person into a country). When creating an entry or adding an objectClass value to an entry, all superclasses of the named classes are implicitly added as well if not already present, and the client must supply values for any mandatory attributes of new superclasses.
Looking at rfc 2252:
The format for representation of object classes is defined in X.501 [3]. In general every entry will contain an abstract class ("top" or "alias"), at least one structural object class, and zero or more auxiliary object classes. Whether an object class is abstract, structural or auxiliary is defined when the object class identifier is assigned. An object class definition should not be changed without having a new identifier assigned to it.
This is all I could find that came close - rfc2251 seems to say servers may disallow changing structural objectclasses on an entry (to prevent changing a user to a country, for example). RFC 2252 actually seems to specifically say you _can_ mix structural objectclasses in one entry.
Did I misunderstand something? If this is actually illegal, does anyone know a reference that documents this? Or am I just completely confused here?
- Jeff
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, ...
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?).
That's a very good question. The "one structural objectclass" rule probably comes from X.500. Can you post this same question to the ldap@umich.edu list? There are many people there who are knowledgeable about the roots of LDAP and X.500 who would probably be able to answer your question.
I believe this is going to become more and more of a problem with LDAP in general - how to create entries that belong to many different objectclasses, if more than one of them are structural? It's almost as if you need an analogous auxiliary objectclass for each structural one.
I've encountered this problem before in Java programming, and I used the following paradigm: create pairs of interface/implementation class. Start with the interface e.g. public interface IDoer { public String getProp1(); public String getProp2(); ... }
Then, create the implementation class: public class DoerImpl implements IDoer { ... }
This idea could be extended to LDAP (albeit clumsily perhaps) e.g. objectclass auxInetOrgPerson SUP 'inetOrgPerson' AUXILIARY to "extend" the structural inetOrgPerson class into an "interface" that could be mixed in with another structural objectclass. I don't know if this is possible or allowed by LDAP or X.500. It would probably have been better to do the obverse e.g. create auxInetOrgPerson first as an AUXILIARY class with all of the attributes, then create inetOrgPerson SUP 'auxInetOrgPerson' STRUCTURAL. But then you would have to do that with all of the superclasses as well: organizationalPerson and person.
Jeff Clowser wrote:
Sorry to dredge up a really old thread, but I've been trying to track down something about it that's been bothering me.
Basically, part of the thread devolved to the idea of creating a single user entry that has objectclasses: inetorgperson, account, posixaccount, shadowaccount, etc. If I understand the response (see below), this violates ldap standards because you are mixing in structural objectclasses and that is not allowed(?)
It was something I hadn't known before, so finally got around to looking for where that was defined.
Looking at RFC 2251:
Each entry MUST have an objectClass attribute. The objectClass attribute specifies the object classes of an entry, which along with the system and user schema determine the permitted attributes of an entry. Values of this attribute may be modified by clients, but the objectClass attribute cannot be removed. Servers may restrict the modifications of this attribute to prevent the basic structural class of the entry from being changed (e.g. one cannot change a person into a country). When creating an entry or adding an objectClass value to an entry, all superclasses of the named classes are implicitly added as well if not already present, and the client must supply values for any mandatory attributes of new superclasses.
Looking at rfc 2252:
The format for representation of object classes is defined in X.501 [3]. In general every entry will contain an abstract class ("top" or "alias"), at least one structural object class, and zero or more auxiliary object classes. Whether an object class is abstract, structural or auxiliary is defined when the object class identifier is assigned. An object class definition should not be changed without having a new identifier assigned to it.
This is all I could find that came close - rfc2251 seems to say servers may disallow changing structural objectclasses on an entry (to prevent changing a user to a country, for example). RFC 2252 actually seems to specifically say you _can_ mix structural objectclasses in one entry.
Did I misunderstand something? If this is actually illegal, does anyone know a reference that documents this? Or am I just completely confused here?
- Jeff
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, ...
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?).
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org
-
Jeff Clowser -
Mike Jackson -
Rich Megginson