Rich Megginson wrote:
David Boreham wrote:
alex@xxxxxxxxxxxxxxx wrote:
I don't have Fedora Directory Server installed (yet). However,
there's one
feature from OpenLDAP that is must-have before even attempting to
play with
FDS.
In OpenLDAP, if I use string like "{SASL}username@REALM" as a value for
userPassword attribute, and have "pwcheck_method: saslauthd" in
/usr/lib/sasl2/slapd.conf, then OpenLDAP will use saslauthd to
authenticate the
user (passing it "username@REALM" and whatever password user
supplied). I've
read that FDS supports SASL, but does it support this feautre too?
Nope.
Is this a currently supported OpenLDAP feature ?
I ask because I vaguely remember some feature like
this being dropped on the basis that it was a stop-gap
until real SASL support was implemented. But I may
well be thinking of some similar but different feature.
FDS does support SASL but I think you'd need to
do some extra work to get it to work with the saslauthd
plugin. GSSAPI and EXTERNAL are the only two
'officially' supported SASL mechanisms.
What problem are you trying to solve? Are you trying to authenticate
apps that cannot use LDAP SASL and must use LDAP Simple BIND, and use
your Kerberos password? Fedora DS has a pam_passthru plugin that might
help you with that. You can tell FDS to use PAM to authenticate the
user, and you can configure PAM to authenticate against Kerberos.
To answer David first. Yes, that is an supported and documented
feature, AFAIK.
Rich, I'm affraid answer to your question will be much longer ;-)
The problem I have is that I need to authenticate users against Active
Directory. There are multiple Active Directory domains for managing
various user groups, each completely independently managed. Windows
uses Kerberos internally for user authentication (basically, every
Active Directory domain is also a Kerberos domain). Suprisingly for
Microsoft, their Kerberos implementation is relatively standard
conformant, and interoperates nicely with Unix Kerberos implementations.
What I currently have is something like this. I have one "corporate"
Kerberos domain. Hosts and services running on my Unix servers are
placed into that domain, as well as several users that don't have
accounts in any of Active Directory domains. Then, I have one-way trust
relationship between "corporate" domain and Windows Active Directory
servers ("corporate" side trusts Windows side to authenticate users).
Now, all Unix based "corporate" services authenticate against
"corporate" LDAP server (and use it for storing all kind of other needed
information). This "corporate" LDAP server will than use saslauthd to
check the password. Saslauthd is configured to use kerberos5 backend.
It simply checks the password against appropriate Kerberos domain for
that user (for most users it will be one of Active Directory servers).
Of course, if the user has Kerberos capable client (usually not the
case) and he has a valid Kerberos ticket, than that would be sufficient
for authentication. Not many client programs on Windows side actually
support Kerberos, so basically they will use classic username/password,
and the Unix side would than check the password against appropriate
Kerberos server as described above. So, the Kerberos here is not used
the way it is intended to be used (single sign on, tickets, and stuff).
It is just used as convinient way for Unix side to authenticate
against Active Directory domains.
Basically, it was a simple way of solving the problem of storing user's
password in single place that could be used by all possibly imaginable
clients and servers running on all imaginable platforms... If I want to
replace OpenLDAP with FDS, obviously I first need to solve a problem
that user's passwords are not going to be stored in FDS. They are
stored in multiple Active Directory domains (the keyword here is
"multiple", which complicates things). In FDS, I could place only the
pointer where the user can be authenticated. In OpenLDAP this was
accomplished by using "{SASL}user@REALM" feature.
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
