problem with GSSAPI and AD solved (when GPO "Domain controller: LDAP server signing requirements" in Active Directory is set to "Require signing")

[Alexey Melnikov]

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