Before we can move onto actually configuring and loading the DSEE with data, there are some concepts and terminologies for the future ldap clients that need to be understood.
Authentication and Encryption options
There are three basic methods to authenticate with the DS, and many methods to encrypt that conversion. This is a very important distinction, but this wasn't made very clear in the official documentation that I've found to date. To make matters worse the terminology used to describe these concepts are very counter intuative.
Authentication to the Directory (Called "credential level" in solaris-ldap-speak)
This is who your ldap clients will connect to the DS as.There are 3 basic choices:
Anonymous
Pretty self explanitory really, clients won't connect as a any specific user at all, this is called an anonymous bind. Bear in mind that this means that everyone (computers or users) connect to your server at the same access level. Ldap clients need write to the directory to perform tasks like password changes which means that you'll have to grant write access not to just everybody, but more precisely anybody with network access to your directory server.I really hope I don't have to explain how dire this is from a security standpoint!
Proxy
This is not to be confused with directory proxy servers, or http proxy servers. This method simply means that all ldap client will share a single username/password. The key difference here as compared with anonymous is that only those clients that already know this shared username/password can connect. Obviously only your known clients should have that password, not the evil hackers! The documentation refers to the ability to create and use multiple proxy accounts across your enterprise, which seems to be something a bit like a rudementary implementation of group based access. This might be useful for segmenting your ldap domain into major business units with different access to different sections of your directory however I expect that if your network is that big/complex than you'll want the next method.
In short, you never ever want to use anonymous, proxy is the more secure and better choice to start off with.
Per user (Kerberos)
This method assumes that each user/host will have their own account with which to access the directory server. This of course will be familiar ground for anyone that's run any Windows AD network. Each of your user's will have their own account in your directory, so why not have them use this account to access the directory, rather than this silly shared proxy account?
It turns out that it doesn't work that way here. Instead the concept of a kerberos user account is entirely seperate from the LDAP record representing a user account's identity.
As we won't be installing kerberos (yet), proxy is the "credential level" that we will use across the Directory Servers.
Encryption (Called Authentication Method in solaris-ldap-speak)
This deals with how to connect with the directory server, rather than as whom.
By using proxy authentication we've stopped just anyone on the network connecting and accessing our directory server, but unfortunately in it's native implementation the proxy user's username & password go across the wire in clear text. *shudder*
In this modern age of switched networks, (rather than "hey, everyone watch my traffic" hubs) man-in-the-middle attacks are hopefully far less common or as easy to pull off as they once were when Solaris 8/9 were making the move to LDAP, however encryption remains a very good idea and it's standard practice in most commercial implementations, such as the Windows AD world.
Unfortunately, based on my experiences setting it up for this blog, the Solaris implementation and easee of setup of SSL for LDAP is decades behind what is found in the Microsoft domain world.
I recommend starting off with encryption optional while you get everything up and running initially.
Of the 8 choices available, there are 3 main ones of interest. I expect the others are more for legacy implementations.
simple:Simple doesn't use encryption at all. Enough said.
TLS:simple:
This method uses SSL encryption for all communication with the DS. Think https, but ldap.
This is the method that this guide will be using, and it's the method that all the other guides seemed to recommend based on my googling at the time.
As I mentioned earlier, unfortunately it does takes quite bit of work o get SSL up and working correctly on clients but fortunately you can specify multiple methods and an order of preference. Therefore we are going to select tls:simple with the option to fall back to "simple" (no encryption remember) while getting initially setup.
sasl:GSSAPI:
This method is exclusively for use with kerberos.
Schema:
Another big surprise for first timers will be the fact that out of the box, DSEE can't work with and doesn't understand how to deal with Solaris clients. I'm just really dumbstruck here.
I would understand if the default implementation needed to be extended in some way to handle non-SUN clients, but in actual fact it can't do anything in it's default configuration. There is no integration whatsoever. SUN - FIX THIS!
For a client to use ldap, the directory needs to be prepped with a Solaris client friendly schema. The second shock to newcomers will be that the DSEE server software doesn't actually come with any software, wizards, or buttons to set it up for Solaris clients.
The 'tool' (a shell script in fact!) for setting up a solaris ldap client friendly schema is found on client machines in /usr/lib/ldap/idsconfig, which comes with the SUNWnisu (Network Information System - usr) package.
This package is included as part of the base Solaris install.
Run this script an any user, and follow the prompts. Most of the defaults will be OK. My configuration summary is belowe, with notes appended where important.
1 Domain to serve : solnet.com
2 Base DN to setup : dc=solnet,dc=com (my test domain)
3 Profile name to create : default
4 Default Server List : 192.168.10.4 (My DS server)
5 Preferred Server List :
6 Default Search Scope : one
7 Credential Level : proxy (Important. Make sure you don't use anonymous)
8 Authentication Method : tls:simple;simple (Important. SSL if possible, but fall back to no encryption while we get setup)
9 Enable Follow Referrals : FALSE
10 iDS Time Limit :
11 iDS Size Limit :
12 Enable crypt password storage : FALSE
13 Service Auth Method pam_ldap :
14 Service Auth Method keyserv :
15 Service Auth Method passwd-cmd:
16 Search Time Limit : 30
17 Profile Time to Live : 43200
18 Bind Limit : 10
19 Service Search Descriptors Menu
Next I ran a bunch of index commands as instructed. In my case I had to change the paths and domains to look something like this for each line:
dsadm reindex -l -t solnet.com.getgrent /var/opt/SUNWdsee/dsins1/ dc=solnet,dc=com
This will create all the additional records and schema information in the directory to service Solaris LDAP clients.
At last you are ready to connect your first client machine, which we will do next.
No comments:
Post a Comment