I'm new to LDAP but have a project that requires it*. I'm looking for suggestions on how to organize the database.
There are three components: users, sites and studies. A user belongs to one site and one study; a site can have multiple studies. A site can also have multiple domains (not just DN entries; they might have site1.org, site2.com, and so on.) Finally, some piece of identifying site and study information is being used in another database -- I can't use the name of the site or study but a UID of some sort would work fine.
My initial stab at this has users, sites and study information in three OUs; each entry has a UID guaranteed to be unique for that entity. Each user entry has a site and a study attribute but their distinguished name is "uid=[username],ou=users". Similarly, the site and studies have DNs "uid=[uidvalue],ou=[site|study]"
I have two questions:
1. Does the above schema make sense? I'm only a little ways along now and would like to make sure I'm on the right path before going too far.
2. How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
Thanks for your help!
-j
(*) Because various services on which the system relies use LDAP for authentication -- and, besides, it seems to make architectural sense anyway
I strongly recommend you use existing schemata. For example:
inetOrgPerson for people
organization or organizationalUnit for sites
domain for domains
not sure what is appropriate for study, possibly documentSeries or document.
To answer your questions:
Does the above schema make sense?
Yes. You should beware the tendency to use the hierarchy to represent possibly temporary organization of the objects in the tree. You should use attributes for that, as you are.
How do I represent multiple domains for the site? It seems like multiple DN attributes would just be confusing, especially since they're simply attributes and not part of the distinguished name.
I don't see that. Multiple DN entries are OK, or multiple domain sub-objects. If a site has multiple domains it isn't appropriate for domain to be part of the DN.
Related
In our website we want to launch country specific domains. so which one is preferred over another like add-on, parked domains or anything that i don't know.
our requirements is quite simple we want to publish country specific domain but the contents are mostly same except some price changes and unique features and/or languages for particular countries. so to take advantage of maintainability we want to use code from single directory in whatever choice we select.
right now we are in impression that we should go with add-on domain but i think we can also accomplish our requirements by using parked domains and detecting from which country domain the user is came from and render content accordingly.
Why not just go with a sub-folder like domain.com/us (for US for example) or maybe even a subdomain (us.domain.com [again, for the US version]) as explained here? Much better and cheaper alternative IMO than buying dozens of country-specific TLDs...
So we have a SharePoint farm that is upon an AD forest, that forest is linked to other forests in a two-way trust.
Then, we have the people picker that is working quite fine and finding every user we try to find, regardless of what domain the user is on.
Now, I need to configure the people picker to find all users from current and future domains in the entirity of the relations BUT one of them. So, it must be a configuration where regardless of what domains, OUs, new or old 2-way trusts are configured, the people picker will find users for all domains BUT one of them.
I've tried to search for an LDAP query that'd do the job to feed to peoplepicker-searchadcustomfilter however could not find it or build it myself. Our AD expert could not get to it too.
I'd rather not use Peoplepicker-searchadforests because later on when they'd add a new domain, someone would have to remember that the people picker needed some configuration. I might be far away when that happens and someone would have to crack his head to find it.
So, from an LDAP Query standpoint, what'd you suggest? Much appreciated.
I am relatively new to chef, so I may be missing something extremely basic. After much searching I am not finding what I need, so here goes:
In Chef, I have roles that are conflicting. I need for all servers of a certain type to have roleA, except for servers with roleB.
The best way I can think of to describe it is with an example:
syslog1, syslog2
web1, web2, web3
db1, db2
mail1, mail2
Every server within this environment(dozens) has a role called syslog_client, except syslog1 and syslog2, which need to have the role syslog_server.
The syslog-server and syslog-client roles conflict, because they configure the same pieces of software differently.
These are roles rather than recipes because they actually encompass several recipes.
I thought of doing something like this:
roles/base.rb:
name "base"
description "base configuration"
override_attributes(
)
default_attributes(
)
run_list(
"recipe[one]",
"recipe[two]",
"recipe[three]",
"role[uno]"
)
unless node[:roles].include?('syslog_server')
run_list('role[syslog_client]')
end
The problem there is that the node object does not exist at this point. I have thought about moving it into the recipe, but I could not come up with a good way to do it there either. I was able to use this in the base recipe:
unless node[:roles].include?('syslog_server')
node[:roles]+=['syslog_client']
end
This adds syslog_client to the roles attribute (or doesn't) correctly, but it never actually runs the syslog_client role.
I have considered moving syslog_client into a self-contained recipe rather than a role, and moving the role attributes to the environment. This would work, because then I can just call include_recipe "syslog::client". The problem there is that virtually all of our recipes are assigned from roles (not from other recipes), and I fear that making this change will create a one-off that will be hard to keep track of. Besides that, as I mentioned already, these are actually several recipes, so adding them as a single recipe is not ideal.
We have many different server types/roles in the environment I'm currently working in, and adding role[syslog_client] to them is feasible, but not ideal. With multiple people working on this, it seems likely that someone will forget to add the recipe to a new role.
In an ideal world, something like my first solution would be possible, because that allows us to keep our environment as consistent as possible. I am open to other options though.
So to wrap up, I think what I need is someone to tell me how to:
Make the first solution work. Add a role to a run list only if another role is not present
If I cannot have #1, I'd like opinions on the best way to achieve this using the ways I've listed or other ideas I have not thought of
Please let me know if I'm missing any details about our chef setup that will be helpful.
Disclaimer: The above example is really a very simplified version of what I'm actually trying to achieve. I'm not even working with syslog, but the company it is for is very security-conscious and would not be happy with details of their environment being posted publicly. I will be as detailed as I possibly can if I've left anything out and I need to add further info.
Extending what was said above what's the issue with creating two roles. A Client and a server
The Client role includes the base role and the client function. It will get applied to all servers through replacing references to 'base' with this role in all other roles. Meaning those roles still get base but get client as well.
The server is a stand-alone role which only applies to those servers and has the base and then the server role?
That way both client and server get the base role applied to them without duplicating the definition of what the base role is. You still manage that base role as you want but you use aggregation in the creation of roles?
When a new role is created the user won't start by adding base but instead adding the syslog_client role which gives them base as well.
To me that feels like the way Chef is pushing you with the creation of roles. What we have is 1 role that applies to all servers, some that apply to 1 subtype of servers but not anothers. That way our leaf role as in the one that gets applied actually consists of 4 or 5 other roles. What's common is modelled in a way that can be shared without the need for logic within?
The other option would be to add the client recipe to every node and the first exeuction step is to check the nodes role and if it says server just basically skip the recipe execution? Which would be the same as the logic which you were wanting to use to add the recipe but it would live in the recipe and control the execution?
unless node[:roles].include?('syslog_server')
#Do your client install
end
I understand LDAP is the protocol which is used to talk to an active directory system like OpenLDAP.
I also understand OpenLDAP is a kind of database which stores objects in a tree.
My question is: When and for what should I use (if at all) LDAP instead of a relational DB.
A relational database and a LDAP based database solve different issues. LDAP is strongly focused on fast-read, slow write, it's hierarchical, distributed, and based on authority (like DNS). If your data don't match this assumption, LDAP is not the right choice.
LDAP works well to describe a hierarchy of entities, like for example a company addressbook. While a relational database would require every department to access the big global table with all the addresses, an LDAP solution allows to distribute the responsibility of each department's addressbook to the department itself, while keeping it available for query to anyone else in the company.
LDAP allows you to store any kind of information. The addressbook is the most typical example, but everything that can be intended as hierarchical, authority-focused dataset can be stored in LDAP. Another example: suppose a library is part of a consortium of libraries, and they want to store data about the books they have. The database is hierarchical (each library is authoritative within its borders) and each library is independent from the others. Inside the schema, you can store data about the books, such as author, publication year, title, isbn and so on.
To store data, you represent it using a special file format, LDIF, but APIs exist as well. LDIF, however, is the most easy way to see the information. it's just a plain text file. An example from wikipedia
dn: cn=John Doe,dc=example,dc=com
cn: John Doe
givenName: John
sn: Doe
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: john#example.com
manager: cn=Barbara Doe,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
This describes the information about a guy called John Doe. It is under the "realm" of dc=example, dc=com, and has a bunch of other information associated to it (think like a table row). Note that the hierarchy can be (apparently) associated to internet domains, like in this case, but in reality the hierarchy description is very flexible. You can organize hierarchies based on national borders or company departments, or anything you like, as you prefer.
You should use LDAP when you need to manage a data domain where you have
the need for a flexible schema with reduced storage requirements.
reduced write needs, strong read needs
strong hierarchical nature of management and organization of information
authorities and delegation of authoritativeness
This concise and nice post has very good info relating to this scenario.
If interested further, you can go a bit deeper in here, which is a continuation to the above link.
LDAP is good for data which is frequently read and rarely written. For example, LDAP is often used to store user login or password information.
LDAP is a centralized user and account management system which can also store some data fields.
You can use LDAP also as lookup-addressing mechanism to retrieve resources, for example Database-Connections or remote-services.
The nice thing I like about LDAP is, that you can retrieve stuff in directory/URL style. This is quite different to RDBMS where you have to use a dedicated query-language. This often makes sense and is intuitive if things are organized in a hierachical way.
Is there a best practice for using email/user accounts for 3rd part APIs in a business scenario?
For example say my company domain is foo.com, and I need to access data from Flicker, youtube, twitter, facebook, jigsaw, Amazon, ebay, and many others.
Should I have seperate email addresses/user names like flickerapi#foo.com,youtubeaip#foo.com, facebookapi#foo.com or something like apiuser#foo.com and have a consitent username used across services if they require a seperate user name? What do you do? Are there any disadvantages or advantages to one or the other? The obvious disadvantage to me of multiple would be remembering all the email addresses.
There are many facets to the answer for this question, and I dont think there is obviously any single superior way.
To be safe you should plan on having multiple, just in case the one you are trying to reserve is already taken (its rare, but it happens). That way you can plan on using a single one but you are prepared if something in your design has to change.
The rest is about visibility, and how risk-averse you want to be. Having one account per service means that if one is compromised (password is discovered, etc) its the only one affected (assuming you use different credentials for each). The downside is that its very obvious these all point to the same place (not necessarily bad) and abuse of one could lead to problems in other places.
Having multiple accounts mitigates some of this, but you have other headaches, such as multiple passwords, managing multiple expiration processes, and auditing to make sure the accounts all still work, etc.