Currently, we have a small group of users that are set-up on an Microsoft SBS machine, hence available under active directory.
These users, as well as a bunch of others also have entries on a second LDAP server (openLDAP). This second server is used for authentication and access control for a few different things such as our internal timesheet web-based system, footy tipping system, forums and subversion repository control.
Thus, for the group that are in the office, they have two separate accounts that they have to remember ID and password for. Some of these internal systems are not easy to configure to authenticate against multiple LDAP servers (mod_authnz_ldap).
For various reasons, we don't want the extra users and groups cluttering up the Active Directory on the SBS machine.
I would love to be able to somehow set up a virtual LDAP server that could work across the two existing LDAP servers and provide a unified view. It would pull the user info from AD, and either from the openLDAP server as well, or maintain the additional users and groups internally.
(Actually, internally would probably be better, as there would be groups that would exist only on the aggregated server, to which we would like to assign users from the AD server as members.)
The only think I know of that is close to doing what I want would be the Penrose virtual directory server, but I wanted to see if there were other options out there before I investigated that much further.
As stated above you can use a virtual directory product to give an interface to a centralized LDAP service.
Some companies that have virtual directory products:
MaXware
Radiant Logic
OctetString
Persistent enQuire
iPlanet Directory Access Router
Oracle
Sun
Many others
What you are looking for is usually called a Virtual Directory, or perhaps an LDAP proxy.
Once you start getting more complex than just two simple systems you want to start thinking about an Identity Management solution, perhaps a Meta directory system.
Virtual directories are nice if that is sufficient, but often it is more expedient to actually collect all the data into one meta directory and expose parts of that as needed.
Lots of products in both spaces, usually cost, as you get what you pay for.
I am not at all sure, but you may be able to do something with ADAM and proxy authentication.
You could at least use the same user-IDs for AD and OpenLDAP. This would solve double user-id problem.
In addition you could automatically sync password from AD to OpenLDAP or other way around. This would solve problem of users having to remember multiple passwords.
Related
I have to develop a Django webapp which can handle several customers with their own databases.
Each customer should manage their different users and groups, with associated permissions and a set of Django's apps.
I need separate databases for security and scaling reasons. Moreover, each base size may exceed 200MB. Besides these dedicated databases, I need a "common" database to store data common to every customer (and must not be replicated to every customer database).
The fact is that I don't know how to handle the multiple customers databases (and keeping Django's auth capabilities for each customer independently : user/group/perms).
I found django-constance (https://github.com/comoga/django-constance) which allow to change settings on the fly, and I have in mind to auth with a customer identifier + username ; this way I may load the right DB with the customer identifier and auth on that one with the username.
Well, this solution does not seem to me so good, and I would appreciate if anybody has a better idea or if someone has already encountered this problem and found a workaround...
I have not found similar problems on the net, and that's quite annoying because that does not seem to me as unusual...
Thanks a lot for the time spent on this.
Keep It Simple -- leverage what Apache (or nginx or whatever) offers you.
Use mod_wsgi.
Use Apache (or nginx or whatever) to split the customer's URL's from each other
/cust1/path/to/resource
/cust2/path/to/resource
If you use Apache (or nginx or whatever) to split these things up, then each top-level path element can direct the request to a specific mod_wsgi instance
Each mod_wsgi instance has it's own settings.py that has the customer's specific database credentials.
Each customer settings.py should probably start with from master_settings import * so that you can have a "for all customers" settings which is extended by each specific customer.
Let's say you have many applications in your environment all of which store their connection strings to SQL Server in a web config. Is it possible to have the application retrieve those connection strings from Active Directory?
We're moving some database servers around and would like a way to have them read from a central location. Active Directory was suggested as one possibility, but we didn't know if it was possible.
This would, in theory, allow us to gradually change our applications to use AD to read the connection strings, then as we move our database servers, make one change in AD to update all the applications.
Is this possible? Maybe you have a better suggestion. Thanks!
Technically speaking, you can't store the information in LDAP since it is a protocol, not a storage mechanism. However, there is no reason (that I know of) that you couldn't store the information in Active Directory or other directory services type engine, and retrieve them with a query from the application. You would just need to come up with some organizational scheme and I would suggest some common code in a library or something that allows you to access the information.
I'm not saying that storing it in Active Directory is the best option, but I believe you should be able to do it without a problem.
We had a design to do that. Our architecture allowed multiple servers, each with multiple databases. We were using Active Directory to manage attributes about the users, including which databases they had access to.
It seemed logical design at the time, since we either had to do that or have a "master" database to direct. Using Active Directory, we no longer had a single point of failure.
Have no idea how it turned out, I left that company.
"The LDAP should be for directory information"
What does that mean? Configuration information is a perfect candidate for being stored in the Dit - it is read intensive, secure, replicated, and easy to access. Most of what is stored in Active Directory is "configuration information".
You can store the connectionstrings about anywhere you want. You could even do them as TXT records on your DSN servers. But you would have to build the resolution framework yourself. Also keep in mind that the connection strings make contain secure information. (such as passwords). If you store these in LDAP (I am speaking genericly for any ldap based server) you will want to make sure the attribute is not public. The upside is LDAP proxy accounts (anonymous connections) would not be able to see the information. The downside is you will have to do an LDAP bind before you can get the information back out of the system. As long as you cache a connection string on the client/server that is going to be making the database calls, you shouldn't see any real performace issues. But if you had to query an LDAP server before each database call you might have problems.
a custom object or even an extension attribute for an exsisting object may be best.
Extend AD Schema
You could create a non-person user and have the connection string be an attribute in the user, but, that would be misusing the LDAP, IMO.
What may be better is to use dependency injection and just have common information such as a connection string, be in one file and just have it either read in when the application starts, or have it be injected in when recompiling.
For example, you could use Spring or Spring.NET, but there are a myriad of DI frameworks that would work.
UPDATE: You could also just create a database table that has this information, and all the applications could read from the database to get all their configuration information.
An LDAP should be used for directory-related issues, I believe, as well as, now, user-management and account information.
In every larger company I worked for they used LDAP as a way to access the central repository of user information, but very few have taken efforts to extend the schema to include objectClasses that aren't derived from inetOrgPerson.
Microsoft's Active Directory makes extensive schema extensions but very few commercial products leverage the capabilities of LDAP.
Is it because most LDAP developers don't know how to model beyond users? Find value in it but just haven't thought deeply about it? Have tried it and ran into performance problems? Something else?l
I've always thought LDAP was too high level for network administrators and too low level for software developers. Neither of them seem to be confortable with it.
There is the perception that since almost every enterprise application will use a relational database, then adding one more data source lowers the availability and reliability for the application.
The barrier to make custom schemas in LDAP is still high. In LDAP servers, you have to put the schema file in the schema directory, usually with root or administrative priviledges an restart the LDAP server; whereas current ORMs can create, update or verify relational database schemas when the application gets started.
Personally I think it's because LDAP is a directory, not a database. Directories are good for looking up people and their associated data, but they're not particularly good for tracking highly relational data -- which is what a lot of the rest of our data looks like. In fact, our use of LDAP is actually as a front-end to "people"-data, merging a lot of data streams into a single directory view. We still have the "people" data in the backend databases along with the rest of our institutional data and have only chosen LDAP (in our case ADAM) as a front-end to allow convenient lookup of the merged "people" data. Now that we're moving to web services as a means of accessing this data, I'm not sure that it even makes sense to continue down the LDAP route (except to support existing services that haven't been updated).
We have done work for some companies with 65Million LDAP records an none of the records were for people.
The data was a variety of items mostly for devices including:
* DHCP
* DNS
* Mac Addresses
* Location
* SN
* Brand
* Model
* etc....
-jim
I would think that it is due to A) the complexity of working with LDAP (much higher than SQL) and B) the fact that your product would be tied completely to it. That is, it would have no market outside of large organizations running LDAP. For less money and effort, I could build an app that works anywhere.
Now, internal applications written specifically for the organization that need access to other LDAP data are a different story. But you will obviously hear less about them because they are not commercially marketed.
I thought LDAP was highly optimized for fast, frequent reads. I don't think they'd scale for transactional systems.
The relational model and its expression in SQL is a powerful thing. I don't think it will be easily supplanted by LDAP or object databases.
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed last month.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Improve this question
I often hear things like "Can we load our employee info using LDAP?" Yet, the title "Lightweight Directory Access Protocol" makes me think of it as a protocol rather than a physical database management system like Oracle or MSSQL.
So could someone please explain to me what LDAP is, how it's used, and how it basically works? Is LDAP simply a standard protocol for extracting data from a variety of DBMSs? In an architecture diagram, would LDAP be simply an arrow drawn between the DB and the application server?
LDAP is a protocol for querying user directories. For example, Active Directory or Novell eDirectory both support LDAP. It is also, to a degree a syntax for doing such queries, like how SQL is a querying language for querying databases.
An LDAP command could look like
(givenName=Mike)
And it would return all Mikes in the directory.
LDAP is usually used as authentication database. Let's say you have CMS product you sell as Software-as-a-Service. So user gets CMS and you maintain it etc.
So, you install it to examplecustomer1.com, examplecustomer2.org, examplecustomer3.net (one software per domain). Now you have THREE user databases to maintain. So you add yourself to all systems as admin and customers accounts as well.
Then you discover LDAP. You add LDAP support to your product and now you have one central database of users. You can login as admin to all systems with your own ONE username and password. CMS system still contains user database and rights for each user but username is now used as reference to LDAP database and password field is deleted from CMS database schema.
Yes, LDAP (Lightweight Directory Access Protocol) is a protocol that runs on TCP/IP.
It is used to access directory services, like Microsoft's Active Directory, or Sun ONE Directory Server.
A directory service is a kind of database or data store, but not necessarily a relational database. The structure is usually much simpler, storing hierarchical collections of name-value pairs, e.g. lastName=Smith, firstName=John.
LDAP IS a protocol, but many people I know like to overload its meaning to include "any store capable of responding to LDAP queries." Active Directory is such a store, and there are many others. It is used when architects don't really care what the store is. It's used in the same as if you were to say "Store it in the SQL" when you don't care whether it's MySql or Oracle or SQL Server.
LDAP stands for Lightweight Directory Access Protocol. This is an extensible open network protocol standard that
provides access to distributed directory services. LDAP is an Internet standard for directory services that run on
TCP/IP. Under OpenLDAP and related servers, there are two servers – slapd, the LDAP daemon where the
queries are sent to and slurpd, the replication daemon where data from one server is pushed to one or more slave servers. By having multiple servers hosting the same data, you can increase reliability, scalability, and
availability.
It defines the operations one may perform like search, add, delete, modify, change name
It defines how operations and data are conveyed.
LDAP has the potential to consolidate all the existing application specific information like user, company phone
and e-mail lists. This means that the change made on an LDAP server will take effect on every directory service
based application that uses this piece of user information. The variety of information about a new user can be
added through a single interface which will be made available to Unix account, NT account, e-mail server, Web
Server, Job specific news groups etc. When the user leaves his account can be disabled to all the services in a
single operation.
So LDAP is most useful to provide “white pages” (e.g. names, phone numbers, roles etc) and “yellow pages” (e.g.
location of printers, application servers etc) like services. Typically in a J2EE application environment it will be
used to authenticate and authorise users.
LDAP is a protocol created in response to the complexity of the X.500 family of protocols. It is intended to represent a hierarchical directory structure. The X.500 standard was originally intended to be used over a complete OSI layer stack and was created to fulfill the requirements of the telecom industry. LDAP was designed to use TCP/IP to provide similar functionality without the extra overhead. You can find information on X.500, OSI and LDAP on wikipedia. X.500 and OSI are both covered in most data communications textbooks as well.
http://en.wikipedia.org/wiki/X.500
http://en.wikipedia.org/wiki/Open_Systems_Interconnection
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
What is LDAP:
All LDAP is a communication protocol which Microsoft implemented for the Active directory directory service and is used for other NTDS.DIT files. Lets get the confusion out of the way. NTDS.DIT contains Active Directory database. To ACCESS the data base you need the communication protocol LDAP. Thats it. So again NTDS.DIT is a simple database i.e ADDS Database (Active Director Directory Services) How do we access it?
We access it using LDAP.
lets use LDAP quick example.
C:/users/data.doc
or
LDAP Syntax
CN=Bob,OU=Users,DC=Youtube,DC=Com
CN = Canonical Name (object or name)
OU = Organizational Unit (Folder in Active directory)
DC = Domain Controller (Where it is)
Other info: Active directory is database based on the X.500 Standard which contains all the AD object which is the NTDS.DIT file.
LDAP is an internet protocol, which is used to look up data from a server, this protocol is used to store as well as retrive the information from the hierarchical directory structure. LDAP also follow a data model whch is hierarchical type. In simple term we can say its a hierarchical database where data is stored in tree like structure where leaf node hold the actual data.
LDAP never define how program function either on the client or server but it explain more about the type of messages that will be used to communicte between client and server. Message can be client requested information , server response and format of the data. These messages arepassed over TCP/IP protocal. So there should be some operation exist that will established a session connection and disconnect it after the operation completion between client and server. LDAP can bes used in the cased where large number of read operations and less number of write operation is required. For example User Authentication as we know that User Name and password are not change so frequently.
LDAP Operations Process
To start the communication, the client needs to create a session with a server. This process is called as binding. To bind to the server, the client has to specify the IP address or the host name and TCP/IP port-no, where the server is attending. The client can also provide credentials like username and password to ensure proper authentication with the server. Alternatively, the client can also create an anonymous session by using default access rights. Or both parties can establish a session which uses stronger security processes like data encryption.
Once the session gets established, the client then performs its intended operation on directory data. In LDAP the directory information can be managed and queried as it provides read as well as update capabilities.
The client closes the session when it finished making a request. This process is called as unbinding.
LDAP Modes
LDAP majorly relies on to the Data Models like
Information model
The directory includes the basic unit of information and it is known as entry, which represents a real-world object like servers, people and so on. Entries include collection of attributes which define information about the object. Each attribute includes Type associated with syntax, and one or more values. The following diagram illustrates the relationship between entry and its attributes and their type & value:
Naming model
The naming model of LDAP denotes how entries are recognized and organized. In LDAP the entries are organized in a hierarchical or tree-like structure called DIT (Directory Information Tree). The entries are ordered within the DIT according to their DN (Distinguishable Name), a unique name which clearly identifies a single entry.
Functional Model
LDAP defines operations requested by a client and can be divided into three categories. They are:
1. Query which is used to fetch information from a directory. Include operations like search and compare.
2. Update which is used to update the information stored in the directory. Include operations like add, modify and delete.
3. Authentication which is used to connect and disconnect with a server, create access rights and preserve information. Include operations like bind, unbind and abandon.
Security Model
In LDAP, the security model relies on the bind operation. Three different bind operations are possible according to the security mechanisms applied. They are:
No Authentication
The simplest method but could only be applied when data security isn’t a problem and where no access control permissions are tangled. For example, the directory includes the address book that can be browsable by anyone. If the user left the DN and password field empty during the bind API call, the server will automatically adopt anonymous user session, and grants access along with the corresponding access controls described for this type of access.
Basic Authentication
Basic authentication is the alternative simple security mechanism used in LDAP and it is employed in several other web-oriented protocols, like HTTP. In this approach, the client has to authenticate itself to the LDAP server by the way of entering a password and DN that is transferred in a clear text over the network. On the other end, the server compares the DN and password with the entries in the directory. And grants access if the password matches. Moreover, the passwords in clear text format can’t guarantee confidentiality; hence, may result in password disclosure to unauthorized parties.
SASL (Simple Authentication and Security Layer)
This framework has been added to LDAP V3 which adds an additional authentication method to connection-oriented protocols. This mechanism specifies a challenge & response protocol where the client and server exchange some data to ensure authentication and establish the security layer upon which the subsequent communication will be carried out. With SASL, LDAP protocol can support any sort of authentication approved upon by an LDAP client and an LDAP server.
Yes, LDAP itself usually requires a lower level DB store.
I suggest you get your hands dirty here:
If you just install OpenLDAP &
play with it... http://www.openldap.org/doc/admin22/install.html
...you will be forced to consider the dependencies.
One of which is, in this case, SleepyCat.
Have fun.
For more fun, here is a good philosophical discussion on the taxonomy:
http://archive.oreilly.com/pub/post/ldap_is_not_a_database.html
LDAP is basically a protocol to access a directory. Directory here basically refers to a directory having information of the users present in the organisation. Examples of directory include Microsoft's Active Directory (AD) and Oracle's Internet Directory (OID). The directory basically are used for implementing the single sign on feature for the organisation by centralising user authentication and authorisation. For more details refer the below links:
http://searchmobilecomputing.techtarget.com/definition/LDAP
https://eagledatagistics.com/what-is-enterprise-user-security-eus/
Here's my situation...
I'm writing a .Net/C# security system (authorization and authentication) for a large collection of web applications that require a single sign-on process. I'm using Active Directory as a data store and have written a very nice prototype that communicates with AD through LDAP. This component retrieves information about the logged in user that I have stored in AD which I then use to set their security roles in .Net forms authentication.
1) All is good.
Not being a System Admin, or Network Engineer, I wasn't familiar with the amount of system administration involved with setting up an AD instance. I wasn't aware that for each domain, I needed a separate server and domain controller. As it turns out, there are like 9 different domains that my team requires to be set up for all of the different environments that we're going to be accessing AD...
env1.dev.mycompany.com
env1.qa.mycompany.com
env1.stage.mycompany.com
env2.dev.mycompany.com
etc
...So now I have placed on upon myself somewhat of an administrative headache because I'm going to have to maintain all of these machines (or VM's), which is something that I'm not necessarily sure I want to do.
2) All is not good.
The prototype is really solid, and AD makes for a very good database for the solution, but now I'm wondering if I should scrap the code and write a SQL Server data provider instead (I know .Net already provides one, but it doesn't alone fit my business requirements for authorization).
Anyway, so I'm trying to think through this problem from a high level perspective. In general, I keep tripping over the fact that I would be throwing a really good solution just because of some server maintenance? I'm wondering if anyone here has experienced a scenario like this and what exactly you decided to do.
Doesn't have to be specific to AD either, just a situation where you had to evaluate between a good software solution and it's server maintenance constraints.
In general, the usability of a product is what makes people to choose between it and similar products. If the product has bad usability, the users won't care how high quality its code is - all that matters to them is how easy and effective it is to use and how well it fills their needs.
Maintenance can be thought as one aspect of usability. I would make it top priority to have an easily maintainable product. In the long run that will save many hours of work from the administrators.
One way to think about it, is first designing what would be the most usable solution from the end user's/administrator's viewpoint, and then making it an intellectual challenge to actually implement that optimal solution. It will probably require more effort from the programmer, but the end result will be better.
For example ZFS is one product where maintenance has been taken care of well (although I have not used it personally). When it was designed, much effort was put into making it easy to administer the file system with ZFS's command line tools - and those design decisions affect all levels of ZFS (for example storage pools).
As another example, I've been recently planning how do maintenance in a future project of mine - a distributed database and application server. Thinking about how typical administration tasks will happen (installing/upgrading applications, adding/removing servers in the cluster, resolving hardware failure etc.), has helped me to sort out some design decisions. Some of them go quite deep into the architecture of the system (for example how applications and extensions are loaded at runtime, and how the servers find other servers in the cluster).
If setting up a single sign on system for a Windows system I be very likly to use AD. As a sys admin. I try to follow a single-source-of-data policy. AD is already holding much of my Windows user/security data. I would prefer to have all in there rather than a second system.
When setting up dev/test/prod environments I try to ensure that the closely match the Prod one, most especially in the area being worked on (where development efforts are being put, etc). So if setting up system to develop an interface with AD I would likely have multiple AD servers.
What options could simplify the admin?
Can you have 1 master server that you maintain in the standard manner and use something like a VMware copy process to maintain all or most of the others? Rather than doing something to 9 servers, keep the other 8 as copies of that mirror the master except for changes made to support dev/test?
Can you run multiple Dev or Test domains from 1 AD server?
Can you script action?
Can you reduce the number of environments, especially at the higher end of test? E.g. provide multiple dev environments and role up releases into a single Test one?
Why not simply use OUs instead of separate domains when testing? That is, have a single domain, but specify that users for particular versions must be found in a particular OU inside that domain. What you would do is in your search functions for looking up users, you'd specify the particular OU as the search root instead of the root of the domain. In each OU you could have ids that incorporate the environment to keep them unique, e.g., user_env1_dev, user_env2_dev, user_env1_qa, ...
I use AD a lot for my apps and never set up separate domains for development/testing.
Use a provider pattern and abstract your datasource calls.
Then you can configure it to use AD or SQL on the fly.
public abstract SSODataProvider {
public bool AuthenticateUser(string u, string p);
}
public ADSSODataProvider : SSODataProvider {
public override AutheticateUser(string u, string p) {
//do auth here
}
}
public SQLSSODataProvider : SSODataProvider {
public override AuthenticateUser(String u, string p) {
//call DB
}
}
public static SSODataProvider dataProvider;
if (ConfigurationSettings.AppSettings["SSODataProvider"] == "SQL")
dataProvider = new SQLSSODataProvider();
else
dataProvider = new ADSSODataProvider();
....
dataProvider.AuthenticateUser("sss","sss");