Re: [SLUG] LDAP config help sought (long post)
Howard Lowndes wrote: snipped My concern, and my reason for originally seeking the hierarchical approach was to limit the level of management access inside the directory, eg. I don't want someone who has write access to domain A being allowed to have read access to domain B, or even knowing that domain B exists. Fundamentally, Address Directory like OpenLDAP is hierchical(inverted tree structured). Can't be otherwise. When I work on OpenLDAP I start with a tree (hierchical) and graphical diagram like so: dn: dc=example,dc=com (can be e.g. dn: dc=slug,dc=org,dc=au or similar) | - | | | dn: ou=People,dc=example,dc=com dn: ou=Computers,dc=example,dc=cometc | --- | || dn: uid=joeblue,ou=People,dc=example,dc=comdn: uid=madamblue,ou=People,dc=example,dc=com etc. joeblue can access only his dn and madamblue likewise by combining: 1. /*User authentication, and Access control list (ACL)*/ E.g.: Check output of ldapsearch -x -D uid=joeblue,ou=People,dc=example,dc=com -w password ldapsearch -x -D uid=madamblue,ou=People,dc=example,dc=com -w password Output only their respective dn's. slapd.conf has: .. rootdn cn=Manager,dc=example,dc=com rootpw secret .. # access to * by self write by users none by anonymous auth by * none after doing following command: ldapadd -x -D cn=Manager,dc=example,dc=com -w secret -f sample.ldif where contents of sample.ldif: # Entry : root organization: dn: dc=example,dc=com dn: dc=example,dc=com objectClass: dcObject objectClass: organization o: example dc: example # Entry : ou=People,dc=example,dc=com dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People # Entry : uid=joeblue,ou=People,dc=example,dc=com dn: uid=joeblue,ou=People,dc=example,dc=com cn: joeblue objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uid: joeblue homeDirectory: /home/joeblue loginShell: /bin/false gecos: Administrator uidNumber: 1 gidNumber: 548 givenName: System sn: Administrator shadowExpire: 21914 shadowLastChange: 12944 displayName: System Administrator - Site A userPassword: password # Entry : uid=madamblue,ou=People,dc=example,dc=com dn: uid=madamblue,ou=People,dc=example,dc=com objectClass: posixAccount objectClass: shadowAccount objectClass: inetOrgPerson homeDirectory: /home/joeblue loginShell: /bin/false gecos: Administrator uidNumber: 1 gidNumber: 548 givenName: System sn: Administrator shadowExpire: 21914 shadowLastChange: 12944 displayName: System Administrator - Site B userPassword: password Hope these help. O Plameras -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] LDAP config help sought (long post)
quote who=Howard Lowndes Now, let us consider setting up my database more like the examples. The questions here are: 1: Can I have more than 1 database bdb entry, say 1 for each of several disparate domains? 2. If I can have more than 1 database bdb entry, can they all co-exist in the same directory path /var/lib/ldap or do they need separate directory paths /var/lib/ldap/firstdomain, /var/lib/seconddomain, etc? 3. Do the rootdn's have to match each dc= for its suffix or can it be quite different, and can I have a common rootdn for all domains? 4. I understand that multiple database bdb entries are permissible and apparently multiple suffix entries are permissible. Are multiple/multiples permissible? 5. If multiple suffixes are permissible under any database bdb entry, then how is the following considered: suffix dc=example,dc=com suffix dc=sitea suffix dc=siteb Is the third line a subset of the second or of the first? Gus gave you great technical answers to your questions - I'm going to focus more on the Zen of LDAP side of things. :-) Sorry that this email is so long, I hope it's worthy of more than a quick skim. Your examples and questions suggest you want to host multiple domains in your LDAP directory, and that you're conflating this goal with the structure of your directory - ie. the generic DN, the multiple db files, domains as dc elements under the generic DN, etc. This is not the way to go with LDAP, and it's usually learned the hard way, because there seems to be a vacuum of written documentation about LDAP best practices. So hopefully this will help a little bit. Firstly, try to keep thinking about LDAP as a directory, not a database. It changes the way you perceive problems, and lets you see past some of the things we assume from database land. You'll often read about LDAP explained in terms of phone books, because they are physical directories. It's handy to use this metaphor, and think about its differences in the digital domain, when dealing with LDAP. For example, a) why do we have separate phone books, and b) why are there different sets for residential and business entries? (a) is easy: it'd be a fucking expensive and unwieldy to produce such a huge book. In the digital domain, we talk about management and scalability. (b) because that's the easiest way to structure the information for humans, particularly that crucial first categorisation step (when you want to get as rid of as much irrelevant information as cheaply as possible), but it'd be pretty hopeless and arbitrary for a computer to deal with, right? So some decisions are based on human management, some are based on computer scalability and application of the data. In the case of hosting multiple domains, your brain *really* wants to conflate all the information about a single domain into a nicely identifiable ball of stuff, whereas the computer (and its software) just has a bunch of unrelated configuration data that happen to work together. WARNING: Do not think of LDAP in general as a management tool, think of it as a directory-optimised data storage and retrieval tool. Management tools are built on top of LDAP, and some are really very cool, like eDirectory and Active Directory. But though they have LDAP at their heart, most of what you see is the management infrastructure. When you're working with OpenLDAP, you are dealing with the storage infrastructure, and usually custom management tools, because we are cheap and dirty and haven't solved many of those hard problems in FOSS land yet. *cough* So, go flat. Put all of the entries for people under ou=People. Their mail attributes will identify them. Put all of the hosts under ou=Hosts. Their DNS attributes will identify them. This will make it easier to configure your applications, and manage changes to your directory in future. You won't need to worry about having separate bdb files until you're really pushing scalability limits - it is transparent and has nothing to do with management of the directory. *Do* think about using one of the simpler backends, such as ldbm. bdb is a pain in the arse to manage, and doesn't give you enough bang for your buck to be worth bothering about (again, until scalability or performance are massive concerns - I was running a very busy 80,000+ account mail server on ldbm). Experiment with your applications and policies before mucking around too much with the details of LDAP. That's *hugely* important, because you can spend a lot of time working around your assumptions if you don't think about your applications before you put your directory together. Finally, go flat. Yes, it's great that LDAP is hierarchical, but it's too easy to abuse and tie yourself up in knots. It's not a benefit, it's a feature. :-) And to finish off... go flat! :-) - Jeff -- GNOME Summit 2005: October 8th-10th http://live.gnome.org/Boston2005 I think hot Chinese girls who kick ass are the wave of the future,
Re: [SLUG] LDAP config help sought (long post)
Flat earth here :) Tks Jeff, that is probably one of the most insightful responses I have seen in a long while, and really does clear some things up for me. I was interested in your comments about bdb -v- ldbm and would be interested in an expansion on that if you feel inclined; I have little knowledge of the workings or vagaries of the Unix dbs. My concern, and my reason for originally seeking the hierarchical approach was to limit the level of management access inside the directory, eg. I don't want someone who has write access to domain A being allowed to have read access to domain B, or even knowing that domain B exists. I have installed phpldapadmin and using that has proved insightful as well as seemingly being a good management tool. Anyway, thanks for you comments. Jeff Waugh wrote: quote who=Howard Lowndes Now, let us consider setting up my database more like the examples. The questions here are: 1: Can I have more than 1 database bdb entry, say 1 for each of several disparate domains? 2. If I can have more than 1 database bdb entry, can they all co-exist in the same directory path /var/lib/ldap or do they need separate directory paths /var/lib/ldap/firstdomain, /var/lib/seconddomain, etc? 3. Do the rootdn's have to match each dc= for its suffix or can it be quite different, and can I have a common rootdn for all domains? 4. I understand that multiple database bdb entries are permissible and apparently multiple suffix entries are permissible. Are multiple/multiples permissible? 5. If multiple suffixes are permissible under any database bdb entry, then how is the following considered: suffix dc=example,dc=com suffix dc=sitea suffix dc=siteb Is the third line a subset of the second or of the first? Gus gave you great technical answers to your questions - I'm going to focus more on the Zen of LDAP side of things. :-) Sorry that this email is so long, I hope it's worthy of more than a quick skim. Your examples and questions suggest you want to host multiple domains in your LDAP directory, and that you're conflating this goal with the structure of your directory - ie. the generic DN, the multiple db files, domains as dc elements under the generic DN, etc. This is not the way to go with LDAP, and it's usually learned the hard way, because there seems to be a vacuum of written documentation about LDAP best practices. So hopefully this will help a little bit. Firstly, try to keep thinking about LDAP as a directory, not a database. It changes the way you perceive problems, and lets you see past some of the things we assume from database land. You'll often read about LDAP explained in terms of phone books, because they are physical directories. It's handy to use this metaphor, and think about its differences in the digital domain, when dealing with LDAP. For example, a) why do we have separate phone books, and b) why are there different sets for residential and business entries? (a) is easy: it'd be a fucking expensive and unwieldy to produce such a huge book. In the digital domain, we talk about management and scalability. (b) because that's the easiest way to structure the information for humans, particularly that crucial first categorisation step (when you want to get as rid of as much irrelevant information as cheaply as possible), but it'd be pretty hopeless and arbitrary for a computer to deal with, right? So some decisions are based on human management, some are based on computer scalability and application of the data. In the case of hosting multiple domains, your brain *really* wants to conflate all the information about a single domain into a nicely identifiable ball of stuff, whereas the computer (and its software) just has a bunch of unrelated configuration data that happen to work together. WARNING: Do not think of LDAP in general as a management tool, think of it as a directory-optimised data storage and retrieval tool. Management tools are built on top of LDAP, and some are really very cool, like eDirectory and Active Directory. But though they have LDAP at their heart, most of what you see is the management infrastructure. When you're working with OpenLDAP, you are dealing with the storage infrastructure, and usually custom management tools, because we are cheap and dirty and haven't solved many of those hard problems in FOSS land yet. *cough* So, go flat. Put all of the entries for people under ou=People. Their mail attributes will identify them. Put all of the hosts under ou=Hosts. Their DNS attributes will identify them. This will make it easier to configure your applications, and manage changes to your directory in future. You won't need to worry about having separate bdb files until you're really pushing scalability limits - it is transparent and has nothing to do with management of the directory. *Do* think about using one of the simpler backends, such as ldbm. bdb is a pain in the arse to manage, and doesn't give you enough bang
Re: [SLUG] LDAP config help sought (long post)
quote who=Howard Lowndes I was interested in your comments about bdb -v- ldbm and would be interested in an expansion on that if you feel inclined; I have little knowledge of the workings or vagaries of the Unix dbs. The BDB backend uses the very latest in highly scalable and pull your hair out with a combine harvester Berkeley DB technology. It's very complex, highly configurable, and requires a lot of babysitting. You end up having to do database recoveries on a fairly regular basis, and have to know all kinds of ins and outs to get the best performance out of it. In most cases, it's just over the top, and the much simpler ldbm backend (which is comparably stupid and slow) saves time in the long run. (It would be interesting to look at Tridge's ldb and tdb solutions for samba in more detail at some stage...) Interestingly enough, this is why the first releases of Subversion always looked like an astounding headsmack expressed in elaborate modern folk dance to me - no way would I put my revision control in the hands of BDB. At least these days they have fsfs and use it by default. My concern, and my reason for originally seeking the hierarchical approach was to limit the level of management access inside the directory, eg. I don't want someone who has write access to domain A being allowed to have read access to domain B, or even knowing that domain B exists. Aha, good reason. :-) Though you could achieve that through other ends, such as putting all of that smarts in your management tools. I have installed phpldapadmin and using that has proved insightful as well as seemingly being a good management tool. It has improved leaps and bounds since I last looked at it - definitely one of the more successful FOSS LDAP tools thus far. I'm really looking forward to how things change with the Fedora Directory Server release, and what the tools are like once they're Freed. :-) - Jeff -- OSCON 2005: August 1st-5th http://conferences.oreillynet.com/os2005/ GDK (acronym): GNU's Not Unix Image Manipulation Program Tool-Kit Drawing-Kit. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] LDAP config help sought (long post)
On 7/14/05, Howard Lowndes [EMAIL PROTECTED] wrote: I'm trying to get somewhere with setting up an LDAP database. So your root is 'o=myhosting' If you want to create 'dc=example,dc=com,o=myhosting' I believe you'll need to create 'dc=com,o=myhosting' first. Matt -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] LDAP config help sought (long post)
Howard Lowndes wrote: I'm trying to get somewhere with setting up an LDAP database. The problem I am encountering is that all the examples that I can find assume the the top level has a dn: of the form dc=example,dc=com such that slapd.conf looks like: ... database bdb suffix cd=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw secret directory /var/lib/ldap ... and the top level LDIF file looks like: ... dn: dc=example,dc=com objectClass: dcObject dc: example objectClass: organization o: Example Company ... My problem is that I want a different top level, and I want my slapd.conf file to look like: ... database bdb suffix o=myhosting rootdn cn=manager,o=myhosting rootpw secret directory /var/lib/ldap ... and the top level LDIF file looks like: dn: o=myhosting objectClass: organisation o: My Hosting Thus far my layout works just fine, but when I come to add dcObjects I start to run into problems. An LDIF of: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example returns the following error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: Object class violation (65) additional info: no structural object class provided If I then expand this LDIF file to: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example objectClass: organizationalUnit ou: My Hosting Perhaps you want this ldif: dn: dc=example,dc=com,o=myhosting, objectClass: dcObject objectClass: organization o: My Hosting dc: example Then, you may create 'ou's after that. I now get this error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: No such object (32) matched DN: o=myhosting or alternatively expand it to: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example objectClass: organization o: My Hosting then I still get the same error message. The question at this point is: What am I doing wrong here? Now, let us consider setting up my database more like the examples. The questions here are: 1: Can I have more than 1 database bdb entry, say 1 for each of several disparate domains? 2. If I can have more than 1 database bdb entry, can they all co-exist in the same directory path /var/lib/ldap or do they need separate directory paths /var/lib/ldap/firstdomain, /var/lib/seconddomain, etc? 3. Do the rootdn's have to match each dc= for its suffix or can it be quite different, and can I have a common rootdn for all domains? 4. I understand that multiple database bdb entries are permissible and apparently multiple suffix entries are permissible. Are multiple/multiples permissible? 5. If multiple suffixes are permissible under any database bdb entry, then how is the following considered: suffix dc=example,dc=com suffix dc=sitea suffix dc=siteb Is the third line a subset of the second or of the first? That'll do for now. TIA. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] LDAP config help sought (long post)
At Thu, 14 Jul 2005 12:28:56 +1000, Howard Lowndes wrote: I'm trying to get somewhere with setting up an LDAP database. The problem I am encountering is that all the examples that I can find assume the the top level has a dn: of the form dc=example,dc=com My problem is that I want a different top level, and I want my slapd.conf file to look like [o=myhosting example] The DN is supposed to be *globally* unique. Hence everyone using some sort of DNS name as the root of the data stored in their LDAP server. (The older convention was o=Company Name,c=AU - but DNS names are better in an internet age) I really think you should rethink your base DN. Note that the DN has very little to do with the actual data stored in that entry (or below that point in the tree) - it just has to be unique. Thus far my layout works just fine, but when I come to add dcObjects I start to run into problems. An LDIF of: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example returns the following error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: Object class violation (65) additional info: no structural object class provided Thats because your objectclasses (only dcObject) are only auxiliary classes that augment other structural objectclasses. You need at least one structural objectclass for each LDAP entry. You might want to consider using objectClass domain for these entries (RFC1274/cosine). If I then expand this LDIF file to: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example objectClass: organizationalUnit ou: My Hosting I now get this error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: No such object (32) matched DN: o=myhosting The question at this point is: What am I doing wrong here? I think that error means you have to create dc=com,o=myhosting first. Now, let us consider setting up my database more like the examples. The questions here are: 1: Can I have more than 1 database bdb entry, say 1 for each of several disparate domains? Yes, if you want. There isn't much reason to actually store the separate domains in separate files however. I wouldn't do it unless I had some technical reason to do so (large databases that want different indexing or different backend implementations, for example). 2. If I can have more than 1 database bdb entry, can they all co-exist in the same directory path /var/lib/ldap or do they need separate directory paths /var/lib/ldap/firstdomain, /var/lib/seconddomain, etc? It looks like it has to be separate directories. 3. Do the rootdn's have to match each dc= for its suffix or can it be quite different, and can I have a common rootdn for all domains? You may specify a rootdn for each database. According to slapd.conf(5), if the rootdn is outside the suffix (namingContext), then the rootpw directive won't work. The rootdn in OpenLDAP is like an LDAP superuser account. The most secure way to use openldap is to never use the superuser account. You can use openldap without specifying rootdn at all and enjoy finer grained access controls. 4. I understand that multiple database bdb entries are permissible and apparently multiple suffix entries are permissible. Are multiple/multiples permissible? yes (assuming I understand your question). 5. If multiple suffixes are permissible under any database bdb entry, then how is the following considered: suffix dc=example,dc=com suffix dc=sitea suffix dc=siteb Is the third line a subset of the second or of the first? Neither is a subset of another in this example. -- - Gus -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] LDAP config help sought (long post)
I'm trying to get somewhere with setting up an LDAP database. The problem I am encountering is that all the examples that I can find assume the the top level has a dn: of the form dc=example,dc=com such that slapd.conf looks like: ... database bdb suffix cd=example,dc=com rootdn cn=manager,dc=example,dc=com rootpw secret directory /var/lib/ldap ... and the top level LDIF file looks like: ... dn: dc=example,dc=com objectClass: dcObject dc: example objectClass: organization o: Example Company ... My problem is that I want a different top level, and I want my slapd.conf file to look like: ... database bdb suffix o=myhosting rootdn cn=manager,o=myhosting rootpw secret directory /var/lib/ldap ... and the top level LDIF file looks like: dn: o=myhosting objectClass: organisation o: My Hosting Thus far my layout works just fine, but when I come to add dcObjects I start to run into problems. An LDIF of: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example returns the following error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: Object class violation (65) additional info: no structural object class provided If I then expand this LDIF file to: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example objectClass: organizationalUnit ou: My Hosting I now get this error: # ldapadd -x -D 'cn=manager,o=myhosting' -W -f myhosting.ldif adding new entry dc=example,dc=com,o=myhosting ldap_add: No such object (32) matched DN: o=myhosting or alternatively expand it to: dn: dc=example,dc=com,o=myhosting objectClass: dcObject dc: example objectClass: organization o: My Hosting then I still get the same error message. The question at this point is: What am I doing wrong here? Now, let us consider setting up my database more like the examples. The questions here are: 1: Can I have more than 1 database bdb entry, say 1 for each of several disparate domains? 2. If I can have more than 1 database bdb entry, can they all co-exist in the same directory path /var/lib/ldap or do they need separate directory paths /var/lib/ldap/firstdomain, /var/lib/seconddomain, etc? 3. Do the rootdn's have to match each dc= for its suffix or can it be quite different, and can I have a common rootdn for all domains? 4. I understand that multiple database bdb entries are permissible and apparently multiple suffix entries are permissible. Are multiple/multiples permissible? 5. If multiple suffixes are permissible under any database bdb entry, then how is the following considered: suffix dc=example,dc=com suffix dc=sitea suffix dc=siteb Is the third line a subset of the second or of the first? That'll do for now. TIA. -- Howard. LANNet Computing Associates - Your Linux people http://lannet.com.au -- When you just want a system that works, you choose Linux; When you want a system that just works, you choose Microsoft. -- Flatter government, not fatter government; Get rid of the Australian states. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
