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/
Related
I am developing a mobile ticketing system, and I'm reviewing my requirements against embedded SymmetricDS. The only sticking point so far is that I can't find any information directly addressing the question of row-level security.
Use Case:
Some of the mobile point-of-sale nodes will be logged in as sellers, some as managers. Everybody can view everybody else's sales. Sellers can create new sales, but never modify them. Managers can modify existing sales, but not delete them.
Problem:
I don't have strict control over the Android mobile POS units, so they aren't trustworthy -- it's not realistic to prevent a malicious seller from decompiling the APK and creating a malicious client node. My environment has security requirements, such that a malicious seller cannot be allowed to modify the sales table on the server. I can trust that the hypothetical malicious seller does not have access to manager credentials, and I can trust that the server software is secure.
Questions:
Is server-side row-level security a job for a load filter?
Can the filter script get access to the node_id originating the change?
Can the filter script get access to the authentication credentials used to register the originating node?
Yes. Some of its is possible implementing with a writer filter, like the update limiting to a certain group of nodes. Disabling deleting a row from a node just means that delete trigger shouldn't be created at all for that node group
Yes, it's possible. Methods that are implemented in an extension of an abstract load file accept arguments that carry external ID of the caller (org.jumpmind.symmetric.io.data.Batch#getSourceNodeId and DataContext#getBatch())
Basic authentication is the same for all nodes. There's a password that is automatically generated when handshake is performed and it's stored in the db. Let your load file implement symmetricds interface ISymmetricEngineAware which allows for injection of an engine that can be used to access the database
I know that there are several similar posts available discussing the same but I didn't find the answer for my case.
I have just basic idea of LDAP which we can get through google search like it is a directory database, used for hierarchical data and optimised for reads than writes. And of course LDAP is protocol to access the database.
A little background of problem:
We have to create a presence service(publish-subscribe) for which we
have to choose between a directory based DB and an RDBMS.
The DB will be on cloud so if RDBMS is chosen it will be exposed as
a Web Service and if a directory based is chosen it will be accessed
via LDAP.
Service is a pub-sub model where each user may be a publisher with many subscriber and it may itself be subscriber. So, it is mn relationship.*
Now, I have two questions regarding the same.
Can we model this in directory based database? I looked through the
schemas but could not figure out how to do that.
Second question is regarding the approach of accessing the data i.e.
using LDAP or using web service. I don't know what are the
advantages/disadvantages of using LDAP over usage of web service.
Appreciate any help.
Thanks
Can we model this in directory based database? I looked through the schemas but could not figure out how to do that.
There isn't an existing schema for this that I'm aware of. All the schemas I've ever seen are for X.500 directory information, not messages or transactions.
I wouldn't give LDAP a moment's consideration for a publish/subscribe system. I wouldn't use a database either. I would use a messaging system, e.g. MQ.
Second question is regarding the approach of accessing the data i.e. using LDAP or using web service. I don't know what are the advantages/disadvantages of using LDAP over usage of web service.
LDAP isn't suitable anyway, and making this decision won't make it any more suitable.
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.
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.