[NTLUG:Discuss] Pre June-meeting discussion [was Saurday]
Leroy Tennison
leroy_tennison at prodigy.net
Fri Jun 15 00:59:34 CDT 2007
Richard Geoffrion wrote:
> Saurday?? :)
>
> Jerome Haltom wrote:
>
>> There's a lot of work to do at the distro/OS level before we have this
>> problem really fixed.
>>
> THIS problem?? what problem is "this' ??
>
>
>> <snip>..nobody wants to actually help on these sorts of issues, either.
>> I guess because they're not cool, and don't use Web 2.0. Or something.
>>
> Well, the basic fundamentals that run the corporate network must not be
> left behind. In the words of a great master.. "First learn stand, then
> learn fly..."
>
>> Also because most people I've met who use Linux have never *really* used
>> Windows on a corporate scale. Alas.
>>
>>
> Well... maybe we won't be like most. :)
>
>
Unless I've missed it "this" could easily be defined as "client
software". We have open LDAP and Red Hat Directory Services to my
knowledge but the only client I am aware of is pam_ldap and, when I
looked at it, there were obvious limitations - at least one of which
still exists (more in a minute).
When I evaluated it you had to hard code the login context into a file
on the host - that's not going to come even close to flying in the
corporate world. The freshmeat site says that the environment is for a
test-based console, although I got it to work from the graphical display
manager you only keyed in a user ID (the context was set). To fix this
not only is the client LDAP code going to have to be changed to accept
(or pick) user-supplied contexts but gdm, kdm, xdm (and maybe a display
manager for xfce) could have to be modified to accept a context as well.
Another issue is that the client password is (or at least was when I
tested) sent in clear text across the wire - need I say more in regard
to the corporate world? I realize that this is "out of scope" as far as
LDAP is concerned but it's still a real-world problem which needs an
answer. The solution is to set up encryption on every host. I couldn't
get it to work then but possibly could now that I've done a lot more
work with cryptography. Even if I can that's another hurdle to
overcome, I suspect that more than a few technicians would feel
intimidated at having to set up encryption by generating keys, etc.
Even if there is no intimidation there's the level of effort involved -
a key pair for every host...
To make matters worse at least some open source developers don't seem to
understand the issue. When I posted on the Fedora Directory Services
forum about this I specifically mentioned the client problem and the
reply I got showed the person responding didn't understand the
significance of what I was saying.
Another issue (at least with open LDAP when I tested) is that you get to
"roll your own" schema. While some standard schemas were supplied you
had to understand how to combine them. This isn't impossible to do but
it does mean that you have to understand LDAP, yet another hurdle.
LDAP itself (regardless of flavor: NDS, AD, Red Hat Directory Server,
open LDAP, etc.) has a hurdle to overcome with the user community which
doesn't "get" contexts. The magnitude of this problem is evidenced by
the fact that Novell came out with Catalog Services in an attempt to
deal with this issue. AD's approach of using domains isn't much better,
users seem to "get that" more but it may be because it's been foisted on
them more. They still don't "get it" easily. The user at domain email
format seems to have some promise because users have to understand email
addresses. However, all this (catalogs, user@) still leads to a more
flat view of user space and ends up presenting scalability problems
(name collisions). Having contexts solves all of this if only the user
community got it... It's simply a tough problem.
Finally, there's the interaction between LDAP and other technologies
such as SSL. I saw a post on the Open AFS forum that some technologies
have to be "first" in authentication priority and of course only one can
be first...
If all of this has changed in the time since I looked at LDAP then
please, PLEASE let me know. This is an area that I'm very interested
in. I believe that, if the open source community had a really good
implementation in this one area, Microsoft might be seeing the exit sign
on a far greater scale at a lot more corporations.
More information about the Discuss
mailing list