I have a web application and I want to control which user can see what data. So I thought a user can belong to a group (ie. DBA, Middleware specialist, UNIX guys, etc.) and the logged in user can only see its data in the app.
I want LDAP to do the authentication. I assume there aren't such groups specified in LDAP (ie. I don't want to use LDAP groups as I cannot force the company LDAP to create groups and put the users in those groups).
What I think of is a flexible solution like being able to use a custom attribute on each user (let's say named 'acces_groups') what the groups can be enlisted comma separated string.
I read that the schema of an objectClass (like organizationalPerson) has to be altered to do that. But is there an easy way to add such a custom attribute to a user in LDAP (I am talking about an already working company LDAP)?
Or how would you solve this (without disrupting/breaking the current LDAP)?
I didn't say what kind of LDAP (OpenLDAP, active Directory, etc.) for a reason as I'd want a common solution here.
These are two possible solutions/implementations :
What you supposed : You can add a schema and not alter the organizationalPerson objectClass. (Because altering an already established schema will make your LDAP not standart)
Then you add this objectClas to all your users to allow them to use the attributes defined by this schema.
You can define the acces_groups attribute and make it multi-value. You could also define one attribute per flag you need dba, middleware, etc. and make it a boolean, etc.
Why I would not do any this :
This is a much more complicated and intrusive way to do it than using built in mechanisms that are readily available in LDAP.
If your LDAP administrator allows youto modify your LDAP schemas like that, it should be no problem to ask him to use groups instead as this method is much less complicated and time consuming to implement
To manage it on daily basis is just a pain because you have no integrity mechanism. All the "CRUD" operations on the "emulated" group will have to be done "manually"
If you want to delete a group, you will have to delete the attribute on all the users who have it set.
If you want to list the "group", you will have to search all the users who have the attribute set with the correct value
etc.
Using groups : You can indeed create groups such as dba, middleware, etc. and assign the users to those groups.
It will allow you the use of group member ship and automatically populate an attribute in your user with the group which he is part of
It is LDAP standart and only need dealing with data than dealing with LDAP configurations (which involves downtime, possible errors/setbacks, etc.)
If your company allows you to modify the LDAP configuration AND the data of the users, then it should also allows you to create groups and assigning people to it
Related
I am trying to build a database that stores Active-Directory entries for users/employees.
Is it safe to assume to query on: (objectClass=person)
What attribute should I store as a unique identifier that isn't the DN? e.g. should I use mail or uid
Also when an employee gets de-activated is there a new attribute that gets added or are they simply removed entirely from AD?
The question asked by you seems to be somewhat opinion based, but I'll talk it from the context of general options available in AD and the usual practices followed.
Is it safe to assume to query on: (objectClass=person)?
All the users created do come under the category of (objectClass=person). But, then if you create a generic-user for having file-share access on a system (through ADUC(dsa.msc) / powershell / C#, etc) which would not be an employee, then in this case it would violate your search condition despite being a person class. I can think of so many other scenarios where it would be impossible to avoid generic-users creation (which would again lie in person objectClass), at least from the viewpoint of mid-sized company and above.
Hence, in such cases it is better to follow a naming convention in your environment to avoid any such confusion. One sample example could be, say set the UPN/sAMAccountName for non-employee users to start from genXXXX, and you'd be easily able to search all employee users henceforth.
What attribute should I store as a unique identifier that isn't the DN? e.g. should I use mail or uid?
There are unique identifiers already available in AD like objectGUID and objectSid. In a domain, the sAMAccountName/UPN values are also unique. But, you cannot rely on that for forest-level search.
objectSid for a user can change when the user is migrated to another domain, but objectGUID never changes. You can read more about SIDs versus GUIDs here.
Also when an employee gets de-activated is there a new attribute that
gets added or are they simply removed entirely from AD?
There is no automatic trigger at AD side. There is an attribute called lastLogontimeStamp which helps keep a track when a user or computer account has logged onto the domain (not the live scenario, but recent one - depending on if it keeps updating properly).
Someone has to manually disable/delete the account if an employee/user leaves the organisation. There are process setup in companies to deal with this scenario where the Access Management solutions are linked with AD modules, and take care of the entry and exit of the users and perform relevant action in AD.
Hope it gives a rough idea of management for the queries raised by you.
I'm modelling a database schema that has the requirement of including multi-user account functionality:
A multiple user account enables multiple users to login to the same
account in order to do the job according to their permission level.
This means that it is possible to maintain a single account for your
entire marketing team. The account owner can add as many users as
he/she wants and limit what permissions each of them has. You can
choose a role for each user: account manager, marketing executive,
marketing assistant, etc… or create a customized permission.
At the moment I have one users table that stores the information of a generic user with the username and password etc. How would one implement a multi-user account functionality? Could an extra field be added to the users table that simply indicates the role? Would a separate table be required? I would like to use the principle of keeping this simple where possible but don't know how to approach this.
Each user is a assigned to one group, is that correct? In that case, the user table can have a groupid which is a foreign key to a user_group table which lists all the access roles that you have.
Now the group (groupid) may have a number of "access rights" of what they can (or cannot) do on the system, which can be defined by you. You can refer to this as a default set of access rights.
If you want to create a customized permission, it's best to read this SO question / the first two answers in the least:
Best Practice for Designing User Roles and Permission System?
In the second example which discusses bitwise operators (if you are doing this custom, without help of a framework as discussed in the first answer), this is interesting assuming you understand the concept. Effectively you are summing up the decimal integers but they are being compared in binary to know what roles are granted for a given user. You can use this concept to also define what access rights each preset groupid has for predefined roles.
For Oracle we have "Virtual Private Database". For SQL Server / Azure we have "Row Level Security". Whichever RDBMS you are using, check for similar feature. It is most efficient for this scenario.
I have an ASP.NET MVC + SQL Server application with 250 simultaneous users daily which uses AD/NTLM SSO to do all the authorization using a custom authorization security class that control access to controllers & Actions based on users & groups.
A dilemma recently came up where the 50K+ account records of the database are going to be managed by different groups to varying degree's:
All users will be able to view most records certain records can only
be edited by certain users/groups of specific departments There will
be an admin & support groups that will be able to edit any group owned records
etc.
This is not a problem of who has access to what features/forms/etc. in the controllers, but instead a dilemma of data ownership restrictions that must be imposed. I am guessing this means I need some additional layer of security for row level security.
I am looking for a pragmatic & robust way to tackle data ownership within the current application framework with minimal performance hits since it is likely the same thing will need to be imposed on other much larger tables of data. Initially there will be about 5 ownership groups, but creeping up to 25 to 100 in the near future.
Sadly there are no cut and dry business rules that are hard and fast that can be implemented here.. there is no rhyme or reason make sense of who owns what except the record primary key id.
To try to fix it I was thinking of creating a table of owner_roles and map it to the users table then create another table called accounts_ownership that looks something like:
tbl(PK),row(PK),owner(PK),view,create,modify,delete
accounts,1,hr,1,1,1,1
accounts,1,it,1,0,0,0
accounts,2,hr,1,1,1,1
accounts,2,it,1,1,1,1
accounts,3,it,1,0,0,0
But in doing so that would create a table that was 250K lines and could easily get some crappy performance. Looking at sites like Facebook and others this must be a common thing that has to be implemented, but I am hesitant to introduce a table like that since it could create serious performance issues.
The other way I thought this may be implemented is by adding an extra column to the accounts table that is a compound field that is comma separated that would contain the owner(s) with a coded set of rights ie.:
id owners
1 ,hr,
2 ,hr,
3 ,hr,it,
4 ,it,
And then add a custom class to search using the 'like' statement.. provided the logged in users role was "it" and the comma's were reserved and not allowed in owners names:
SELECT * FROM accounts WHERE owners LIKE '%,it,%'
... however this really just feels wrong from a DBA perspective (ugly as hell) and a maintenance nightmare.
Any practical approaches on how I could implement this without destroying my site?
Start with Role-based access control, you can possibly skip the roles from the pure definition but should be able to implement it like this:
Every user can be in one or more groups like admin, support, it, hr
Every data row has an owner like it, hr
On Access, check the access: an admin can see and edit all rows. Support+it sees every row and can edit those from it etc. This way you need only (user-groups + row-access) new rows in your database, not (user-groups * row-access).
User groups in your scenario should be possible to hardcode in your application, in a CMS there is generally a table defining what rights to assign to each user group - complicating the coding but very flexible.
Roles in the original concept allow a user to select what rights he/she wants to use, there would be a "Unlock with admin rights" or the like in your interface.
Primarily for performance reasons, I went with the less elegant approach listed. It took some doing, but there are careful application controls that had to be created to enforce things like no comma's in the id's.
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/
When querying with LDAP against our Active Directory structure to look up user accounts, some records (but not all) are missing certain key fields, specifically memberOf and userAccountControl (which has a bit flag that indicates whether the account is disabled or not).
Here's a few refining details:
If the query is set to filter on any
of those fields (such as getting a
list of non-disabled accounts in the
Marketing department group), they
disappear from the result set (since
as far as AD is concerned, they're
missing).
If the query is performed
with a highly-privileged domain
admin account, the query works just
fine.
The records with the problem is about 1/4 - 1/3 of the total user records. Most do seem to be newer records (we thought for a time that it was perhaps related to upgrading to 2003 on the domain controller server), although some older records seem affected as well.
A cursory look over two similar records, one whose entire record is viewable by any account, and another which isn't doesn't show any obvious differences.
So my best guess is that there's some sort of permission deny set (perhaps at the schema level?) which makes certain fields restricted. I should note that the domain administrators never knowingly set any such permissions.
UPDATE/RESOLUTION: ADSI Edit (in Windows 2003 Support Tools) helped me to nail it down to a change in the default permissions on the Authenticated User role. For some people, the role contained the Read Account Restrictions (which contains userAccountControl) and Read Group Membership (memberOf), and for others it didn't.
The original cause of the difference still isn't clear, although the fact that most of the "bad" records were created after a switch to Windows 2003 for the Domain Controller, that could be a factor.
SOLUTION: This is still a bit undecided, but will most likely be an updated Group Policy, combined with a script to update existing accounts.
You can check the permission on the specific field of the specific users with adsi edit. Somehow thay must have been changed, and you will have to restore them to default. Maybe they where changed in the ou level of some of the users. In this case you can mass fix them.
What is of interest is that both the attributes you suggested are sort of read only. Member (attribute on a group) is maintained in Active Directory. The MemberOf value on a User is calculated based on a query, and is not actually statically stored on the user object.
I am pretty sure userAccountControl is a read only attribute as well, via LDAP. (Other approaches are needed to manipulate it directly.).
Not sure if that helps, but might be a hint in the right direction. (Or else totally wrong..)