mikbec wrote:
Hello all together,
Hi,
Sorry for my belated response.
all about I talk in this mail isn't really an OpenLDAP problem because
OpenLDAP makes use of SASL implementations to support GSSAPI stuff for
authentiation, signing and encryption. It does not provide its own
GSSAPI implementation. Cyrus SASL GSSAPI is mostly used to provide
that GSSAPI (or GSS-SPNEGO) feature.
OpenLDAP client library stuff is often used to communicate to LDAP
servers of different vendors. And one really often used LDAP server
is Active Directory from Microsoft to manage computing environments and
user (or computer) identities. If Services For Unix (SFU) or at least
Win2k3R2 is used on Domain Controllers UNIX UIDs/GIDs are manageable by
AD too. But now comes the problem for UNIX/Linux clients.
Normally you get only connected to an AD as non-Windows client
when using SSL/TLS over LDAPS or turn of LDAP server signing
requirements. This will be done via group policy object
-> GPO: Domain controller (GPO in OU=Domain Controllers,DC=...)
-> Computer configuration
-> Windows Settings
-> Security Settings
-> Domain controller: LDAP server signing requirements
where value is set to "None". But then (unless the client requests data
signing and the server supports it) LDAP communication is plain and the
client could not be sure that it comes from the server.
For UIDs/GIDs this is a great problem and the use of LDAP is then not
better than the use of NIS.
Thats why most AD infrastructures setting the value of that GPO to
"Require signature". That isn't a problem for Windows clients because
they use Kerberos session key for signing.
But for OpenLDAP clients this is a problem. They could not talk to that
AD-DC anymore. Only authentication works but LDAP communication signing
not.
So here (at the end of this mail) is a code snip set for Cyrus SASL
GSSAPI plugin that solve this problem.
description
-----------
A client which talks to an AD-DC (tested with Win2k3R2, Win2k8 or
Win2k8R2 as AD-DC and GPO "Domain controller: LDAP server signing
requirements" is set to "Require signature") gets the following
requirements for SSF
--->>> line 1620 cyrus-sasl-2.1.24/plugins/gssapi.c)
(allowed == 214748647 && need == 0 && (serverhas == 7)
This means for AD: the LDAP-GPO is on, so we should say we do signing
(but in real we do encryption) and say both.
This seems to be the same issue as reported by Nico Williams. The main
problem here is that AD is expecting both integrity and confidentiality
bits back from a GSSAPI client (value 6), while Cyrus SASL is only
returning one of the bits (and confidentiality implies integrity).
I have some other changes in this area and will use a slighly different
approach to fix the problem. I will introduce either a new SASL option
or a new params->props.security_flags flag to enable AD-compatible
behavior.
Another point in case of GSSAPI is the SSF isn't really relevant. GSSAPI
code negotiate the encryption and signing algorithm depending on
Kerberos session keys of involved server and client.
Yes. But there is no GSS API for extracting cipher strength.
If you have any ideas about how to get the right value, please let me know.
So our solution should be an additional case where we choose
oparams->encode = &gssapi_privacy_encode;
and answer to the server we can do what he can do
mychoice = (severhas & 7);
Now GSSAPI(/Kerberos) based communication to AD-DC works. Thats it.
Hope this little patch gets into Cyrus SASL code.
[...]
Best Regards,
Alexey
--
IETF Application Area Director, <http://www.ietf.org/IESGmems.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
