openldap and FDS

[Craig White]

On Sat, 2007-03-10 at 12:51 -0600, Les Mikesell wrote:
> Craig White wrote:
> > ----
> > FDS isn't installed by default because there is simply no justification
> > for doing so. All of the applications/daemons that have ldap client
> > libraries compiled in as options 
> 
> Are you saying these don't follow standards and thus interoperate correctly?
----
of course not - both FDS and OpenLDAP incorporate a substantial portion
of LDAPv3 standards.
----
> 
> > So instead of installing OpenLDAP-Server you can install FDS and the
> > choice is really up to the system administrator but neither is suitable
> > as a default install.
> 
> I agree that they aren't suitable, but don't understand why this wasn't 
> fixed years ago.  How is someone with a few machines supposed to make 
> their accounts work everywhere?
----
the OpenLDAP client software is included and compiled into virtually all
potential client applications on Fedora & RHEL that I have run into
which on my FC-5 desktop here includes:
autofs, cyrus-sasl, ruby-ldap, evolution-data-server, samba, httpd,
subversion, apr-util, opal, python-ldap, php-ldap, sendmail, mod_perl,
nss_ldap, wine-ldap, squid, kdebase, nfs-utils-lib, libuser, GConf2,
postfix.

So in answer to the second question...the implementation of account
management via LDAP is left to the administrator as opposed to the
predetermined methodology incorporated into Windows Active Directory.
----
> 
> > The point I was trying to make about needing to be versant with command
> > line functionality of LDAP was this...if you can't query/maintain LDAP
> > from the command line, you are never going to be able to debug/analyze
> > how other applications interact with your LDAP server since LDAP doesn't
> > operate in a vacuum.
> 
> Why is this any more true for LDAP than any other protocol?   Do you 
> need to understand imap command line tools and protocol analyzers to use 
> email?
----
I'm not certain that this is more true for LDAP than any other protocol.
What I know is that LDAP directory design has no prescribed correct way
for setup except for Windows Active Directory. FDS has a prescribed
notion on initial setup but it is easily modified which is what I
suspect that most people actually do.

I suspect that samba will actually drive some standardization because
samba is designed specifically for interchangeability with Windows
systems and Samba 4 is trying to become interchangeable with Windows
Active Directory and if you want to track the DSA design they are
recommending...

http://wiki.samba.org/index.php/3.0:_Initialization_LDAP_Database

I'm not sure that it serves the open source community to have Microsoft
dictating LDAP design though.

But in answer to your second question, if you run an IMAP server, you
definitely need to know imap command line functions at some point to
debug...

# telnet srv1 143
Trying 192.168.2.1...
Connected to srv1.azapple.com (192.168.2.1).
Escape character is '^]'.
* OK srv1.azapple.com Cyrus IMAP4 v2.2.12-Invoca-RPM-2.2.12-9 server
ready
. login craig XXXXXXXXXXXX
. OK User logged in
. LIST INBOX *
* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.App-Server"
* LIST (\HasNoChildren) "." "INBOX.Catchall"
<snip>
. logout
----
> 
> > LDAP is only useful when you link in other
> > applications and if you don't understand how they do that, you are going
> > to get nowhere.
> 
> Again, why is LDAP any different in this respect that the other methods 
> doing the same jobs now - that most people use without understanding? 
> PAM should be covering up most of it anyway.
----
I presume when you mention PAM, you are specifically referring to LDAP
as an account authentication system.

With respect to this functionality, there are a number of steps that are
necessary in order to accomplish this...
configure /etc/nsswitch.conf # somewhat accomplished by authconfig tool
configure /etc/ldap.conf     # somewhat accomplished by authconfig tool
configure /etc/pam.d/system-auth # accomplished by authconfig tool
generate server & client certificates for TLS/SSL and put into place

I am presently accomplishing this through fedora kickstart installs and
on first boot, anyone permitted can login and it's not very difficult at
all.

The issue of practicality cannot be ignored though. If you want to set
up and test, you really need a fast method and that is the command line.
More to the point, once you can do command line client tools that
openldap-clients package provides, your understanding grows and all
things become understood. The GUI tools simply do not fill the gap of
knowledge but they can provide easy access to data maintenance.

Craig