| LDAP can be used to store lots of system information. We are
currently using LDAP to store user account information, in the
People organizationalUnit (OU), group information in the Group OU,
SAMBA domain machine account information in the Machine OU, and
administrative information in the Etc OU. |
|
The LDAP data is used in many ways by the different elements of
the network. |
|
FIXME: Discussion of each use case could go here. |
| Our default LDAP configuration has one administrative account
that has been given all forms of access to anything. Anonymous
users can read just about anything. The only exceptions are
userPassword, ntPassword, and lmPassword. These require the
administrative account. |
| With an LDAP configuration that has one administrative user and
that user is the only one able to access the userPassword and other
sensitive pieces of information, the Unix Client, the Mac OS X Client,
and SAMBA all have to be given the same access privileges as the
administrator. Otherwise, they will not be able to retrieve the
*Password hashes to authenticate users for logon. |
| Enter The Black Hats
The ``Black Hats'' are the bad guys. They want access to your information,
but you don't want to give it up. Here are some categories to consider:
- Network access to LDAP server.
This is just some random computer on any network browsing the
contents of your LDAP server. This is happening as you read...
The intent of a Black Hat here is to find information to gain
access at a higher level.
- User-level logon to client machine.
These are your normal network users. They may be people in
your organization. Some you may trust, others you may not.
Still others may be external Black Hats that have broken into
a user's account.
- Root-level logon to client machine.
You may be the administrator for all of the machines you are
charged to support. If so, count yourself lucky. The rest of
us need to consider the guy down the hall that fancies himself
an administrator, sets up his box, and uses politics to force
his way into your network. Not that he's a bad guy, but you
certainly don't want him to have read/write access to your entire
LDAP database. One simple mistake and your whole database is
ruined. One simplier mistake (user=root, password=toor) on his
machine in somebody else could be using your LDAP admin password...
This Black Hat effectively owns your network.
- User-level logon to server machine.
These are your normal network users. They may be people in
your organization. Some you may trust, others you may not.
Still others may be external Black Hats that have broken into
a user's account.
- Root-level logon to server machine.
During normal operations this root needs to be able to do various
system duties for your LDAP system. It needs access to the LDAP
admin password. However, if it is compromised, then you are
in for a long weekend (or worse) while you start over.
Restrictions
Now, we need to make life as difficult for the Black Hats as possible,
while allowing our systems to run smoothly with minimal amounts of
effort on our parts. Here are some LDAP security measures to limit
the possible damage to the LDAP system.
- Network access to LDAP server.
Use port filters to restrict LDAP access to your network
from outside.
Use LDAP access restrictions to limit anonymous access to
only those things that are essential.
- User-level logon to client machine.
Store the LDAP password in the ldap.secret file. Make this
file only accessible by root.
- Root-level logon to client machine.
Make the root of client machines only able to read the password
information, not be able to modify anything in the LDAP server.
- User-level logon to server machine.
Store the LDAP password in the ldap.secret file. Make this
file only accessible by root.
- Root-level logon to server machine.
If this is compromised, you have too many problems to be discussed
here.
Access Needs
The other form of restriction is ``need to know''. Restrict everything,
and only open up access on a ``need to know basis''. We will use the
use case diagrams from earlier in our discussion to find out who
need to know what. |
- Unix Client
Normal users need to read posixAccount and posixGroup information.
This allows ls, and other such information commands to work. This
does not include the userPassword attribute of posixAccount.
The root user needs to read userPassword information, as well as
other posixAccount and posixGroup attributes.
- OS X Client
Much the same as the unix client.
- SAMBA
SAMBA needs to read most posixAccount, posixGroup, and sambaAccount
attributes. The userPassword is not needed. ntPassword and lmPassword
are needed.
The sambaAccount information of machine accounts are also needed.
Finally, SAMBA needs to modify the ntPassword and lmPassword fields
of the user accounts.
- System Administration Tools
Needs to have full priviliges.
Configuration Solutions
The above groupings of access needs suggest a set of LDAP access accounts
with various privileges.
- userLevel
This access will allow the reading of posixAccount and posixGroup with
the exception of userPassword.
To be used in the normal binddn and bindsecret of unix client machines.
- rootLevel
This access will allow all privileges of userLevel with the addition
of reading userPassword.
To be used as the rootbinddn and ldap.secret of unix client machines.
- sambaLevel
This access will allow read of posixAccount, sambaAccount, and ou=Machine
information, with the exception of userPassword.
Also will allow modification of ntPassword and lmPassword.
To be used as the SAMBA 'ldap admin dn' and secrets.tdb entries.
- adminLevel
This access will have full privileges.
To be used by the System Administration Tools.
|
