You can look at this from 2 perspectives. One is LDAP access control,
and the other is application level access control stored in LDAP.
Access control within LDAP is simply setting up ACI's that restrict
access to LDAP data based on certain rules. Note that LDAP access
control is implementation specific - there is no standard, and each
server does it differently. Also, LDAP ACI's have certain limitations -
you can limit who can write to an attribute, for example, but it's hard
to limit _what_ they can write to an attribute they have write access to.
Application level access control is done by the application being able
to see data in LDAP, and making decisions about what access to give
based on that data.
An example of using LDAP ACI's for access control:
- Define write access to a branch of your ldap tree based on an admin
group in ldap. Only members of that group can write to that branch, so
only those users can create entries in that branch.
An example of application level access control:
- A VPN server looks to LDAP for users and groups. It authenticates a
user against the user entry (say with a username/password or certificate
in the users LDAP entry). It then looks at a template entry (which may
be an extension of a groupofuniquenames group, for example) that defines
privileges (such as what hosts a user can get to, what time of day they
can access things via the VPN, etc). If the user is a member of that
template/group, they have the access defined in that template.
What is used is heavily dependent on the application/service you are
trying to tie to LDAP. It really comes down to what the application
expects to be in LDAP and how it interprets it, and each application is
likely to do something a little different. Some applications are more
flexible about what you can configure it to look at, while others
require you to install specific schema extensions and populate entries
with data around that.
As a third example, consider an application that uses both aci's and app
level access control:
- an admin tool that allows you to manage users. You can define LDAP
aci's on a branch of your ldap tree that contains users. The acis limit
write access to that branch based on an admin group in ldap.
- The application only offers the user admin page if you are a member
of this group. Furthermore, it only allows you to create _users_ in
that branch - no groups, etc. These are application level restrictions.
As a forth example (and one similar to what you proposed), you can
sometimes combine aci's and application level access control to get
around some limitations in the service that is using ldap:
Say we have a server that looks at ldap for user authentication. If it
finds the user, it allows it in, and that's all it can handle. However,
we want to limit users to certain machines, but the application doesn't
provide for this kind of limitation.
We can extend a users entry - say we define objectclass appx, with one
multivalued attribute called appxhosts.
In a users entry, we add objectclass appx, and populate appxhosts with
the list of hosts we want that user to access.
We then create appropriate aci's for each server such that the server
can only see entries with appxhosts=hostname of the server looking up
users for authentication.
If the server can't "see" the user in LDAP when it looks up their uid,
it can't authenticate them, and you effectively limit which servers a
given user can log into.
This example is a bit oversimplified - if you allow anonymous access,
you have to prevent that access from allowing the server to see these
users, etc, but it gives a reasonable basis to work from. BTW - this is
not the only way of doing this - with FDS, you can also use roles, you
can probably do similar things with groups, etc - sometimes you have to
be creative, and different apps will limit what you can do in different
ways.
Anyway, what you'll find in the end is that you'll have to figure this
out for each service you integrate against your ldap service - every one
works a little bit different. There is no generic, universal answer :)
- Jeff
speedy zinc wrote:
Hi all,
Sorry if the question is not FDS-specific. I'm a
university student and trying to learn how LDAP is
used in managing access control. I can setup FDS,
create basic schema (mostly user information), setup
postfix to use FDS as authentication server, set up
PAM on linux to use FDS as authentication server, etc.
But that's only limited to user authentication.
Everyone is talking about how LDAP can be used to
manage access, in fact, it is on every vendor's
features list. But I've never seen a real example of
how it is used. Maybe I'm dumb, but I just couldn't
imagine how it is set up and used.
Let's take the following scenario.
I have a network of servers, running different
services and applications. Let's say, I called my
machines M1, M2, M3, and called the services S1, S2,
S3. All machines runs all 3 services. I have 3 groups
of users, G1, G2, G3.
Now, the question is, how can use LDAP to manage
access control of my users? Let's say, I want to let
users in G1 to access S1 and S2 on M1 only. And here
are the requirements:
G1 -> M1(S1, S2)
G2 -> M1(S3), M2(S1, S2, S3)
G3 -> M3(S1, S2, S3)
Maybe I'm not understanding the meaning of "access
control" correctly. But I just could not figure out
how to set up to achieve this goal.
What I want to know, besides the standard schema for
storing user information, how do I:
- define the schema for storing access control
information?
- tell the servers and services that specific user has
what access permissions?
- define extensible schema, so that if I add more
servers and applications to my network, I can add new
access control information without having to re-design
the schema? If I have to use any features that are
specific to FDS (ie. non-standard), so be it.
Gurus on this list, mind giving any hint on that? Or
if anyone could give a real life example, that would
great.
Thanks in advance
sz
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
