Openldap supportedControl Password Policy

Openldap supportedControl listed: 1.3.6.1.4.1.42.2.27.8.5.1 (Password policy)

Using .Net DirectoryServices.Protocols, I've exhausted all possible methods of retrieving the response information provided by this control.

I'm using the latest Openldap Source built/running locally in a Cygwin environment with all PPolicy related config enabled in the build and the PPolicy configured and work开发者_如何学编程ing/tested.

By modifying an example from the directory services programming guide, link: http://dunnry.com/blog/2006/05/11/DotNetDevGuideToDirectoryServicesCompanionSiteLaunched.aspx

, to use a SearchRequest populated with a DirectoryControl configured to request the

Password Policy, gets me nothing. Everything looks good in the Server Source: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob_plain;f=servers/slapd/overlays/ppolicy.c;hb=HEAD

Has anyone had any luck using .Net DirectoryControls in a SearchRequest?

Here is some code I've been trying:

    _authConnect.AuthType = AuthType.Basic;
// credentials.UserName is a user DN format, w/password and null domain
_authConnect.Credential = credentials;
Debug.WriteLine("PV: " + _authConnect.SessionOptions.ProtocolVersion);

var sr = //new ExtendedRequest();
         new SearchRequest(credentials.UserName, "(objectclass=*)", SearchScope.Base, null);
         //new DsmlAuthRequest(credentials.UserName);
        var isCritical = false;
    var ppolicy = "1.3.6.1.4.1.42.2.27.8.5.1";
        // ppolicy request and response control is referred to by the same OID
        sr.Controls.Add(new DirectoryControl(ppolicy, null, isCritical, true));
    sr.Controls.Add(new DirectoryControl(ppolicy, new byte[8], isCritical, false));

try
{
  var response = (SearchResponse)_authConnect.SendRequest(sr);
  DirectoryControl[] c = response.Controls;
  if (c.Rank > 0 && c.GetLength(0) > 0)
  {
     Debug.WriteLine(c[0].Type + " value: " + c[0].GetValue());
  }
  SearchResultEntry entry = response.Entries[0];
  c = entry.Controls;
  if (c.Rank > 0 && c.GetLength(0) > 0)
  {
     Debug.WriteLine(c[0].Type + " value: " + c[0].GetValue());
  }  
  return true;
}
catch (LdapException ex)
{
  Debug.WriteLine(ex.Message);
}

I had the same problem as you and tried many things unsuccessfully and then ran out of time. The problem as I noticed was that openldap was only sending the password expiration information in the bind request. I found this out by enabling all logging on the server. So I went about trying to find a way to use directory controls with a bind request. There wasn't a way to do it using S.DS.P LdapConnection class that I could find. I then went about hacking around with reflecting into the connection object and grabbing the ldaphandle variable. With that I could use it to call into the c-api directly like S.DS.P does. I looked around at the openldap sources and noticed that its tools use a sasl bind mechanism with no mechanism which in that library resorts back to a simple bind with the controls. It doesn't work the same in winldap. If you do that it will return a bad parameter response code. The last thing I tried was calling the async version of ldap_bind and reading back the message. Unfortunately no controls were ever in the response. I think since I wasn't sending them they weren't getting returned even though the openldap log file said it was setting the warning. That was my only hope for using any of the built-in winldap bind methods.

The last thing I was going to try but ran out of time would be to construct my own bind message with the controls and send them to the server using the ldap_extended_operation_s function. http://msdn.microsoft.com/en-us/library/aa366580(v=VS.85).aspx If I get some extra time on this project I may go back and try that out. If I do I'll report back here. Ultimately though if this is the solution it may just be easier to use the ldapcsharp library from Novell. It looks like it is possible to send a bind request with server controls using it. I only explored the winldap api because I'm somewhat familiar with it and we're already pretty entrenched with using DirectoryServices.Protocols already.