Using built-in IIS AD authentication by PHP CGI under an IdentityPool












0















I have a PHP website running as an App on IIS.



The app is using a specific Identity that runs all php-cgi.exe processes under NetworkService user that has access to the AD server.



There's also another .NET app in the IIS where it's using the same identity and can log into the AD using the class System.Web.Security.FormsAuthentication and uses Forms Authentication in the Authentication settings in IIS. I tried copying the settings over but to no avail.



The .NET code:



...
using System.Web.Security.Membership.ValidateUser;
...

public ActionResult Login(Login model, string route)
{
if (Membership.ValidateUser(model.Username, model.Password)) {
FormsAuthentication.SetAuthCookie(model.Username);
return Redirect(route);
}

return RedirectHome();
}


My code running on IIS with PHP CGI, impersonate is on on IIS level and php.ini level:



public function login()
{
$ldapHost = 'ldap://spacemudd-ad';

// PHP should use server's (iis) credentials when connecting. (impersonate)
$connection = ldap_connect($ldapHost);

// This always fails.
//
// "ldap_bind(): Unable to bind to server: Can't contact LDAP server"
//
// I believe due to the php-cgi.exe not sending the request
// to the AD server through the IdentityPool's user (NetworkService)
// even though in the TaskManager, the php-cgi.exe shows the owner is
// NetworkService?
//
$ldapBind = ldap_bind($connection);

// TODO: Search the AD directory for the user to be authenticated.
}


php.ini configuration:



fastcgi.impersonate = 1



ref. questions:




  • Setting permission for PHP (or I_USER [I'm not sure here...]) to connect to iisweb.vbs


  • Impersonate Domain User with Integrated Pipeline


  • https://serverfault.com/questions/313100/iis-forms-authentication-php-asp-net-server-side-login (didn't attempt but looks promising -- will attempt tomorrow)


  • PHP LDAP binding AD with the server's user account (doing ldap_bind() without setting credentials)





Update 24-11-2018: The sysadmin gave me these information:



config.md:



 <add name="ADConnectionString" connectionString="LDAP://spacelantern-central/DC=spacelantern,DC=com" />

<membership defaultProvider="ADMembershipProvider">
<providers>
<clear />
<add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" />
</providers>
</membership>


code.md:



if (Membership.ValidateUser("userid", "password"))
{
//
}









share|improve this question





























    0















    I have a PHP website running as an App on IIS.



    The app is using a specific Identity that runs all php-cgi.exe processes under NetworkService user that has access to the AD server.



    There's also another .NET app in the IIS where it's using the same identity and can log into the AD using the class System.Web.Security.FormsAuthentication and uses Forms Authentication in the Authentication settings in IIS. I tried copying the settings over but to no avail.



    The .NET code:



    ...
    using System.Web.Security.Membership.ValidateUser;
    ...

    public ActionResult Login(Login model, string route)
    {
    if (Membership.ValidateUser(model.Username, model.Password)) {
    FormsAuthentication.SetAuthCookie(model.Username);
    return Redirect(route);
    }

    return RedirectHome();
    }


    My code running on IIS with PHP CGI, impersonate is on on IIS level and php.ini level:



    public function login()
    {
    $ldapHost = 'ldap://spacemudd-ad';

    // PHP should use server's (iis) credentials when connecting. (impersonate)
    $connection = ldap_connect($ldapHost);

    // This always fails.
    //
    // "ldap_bind(): Unable to bind to server: Can't contact LDAP server"
    //
    // I believe due to the php-cgi.exe not sending the request
    // to the AD server through the IdentityPool's user (NetworkService)
    // even though in the TaskManager, the php-cgi.exe shows the owner is
    // NetworkService?
    //
    $ldapBind = ldap_bind($connection);

    // TODO: Search the AD directory for the user to be authenticated.
    }


    php.ini configuration:



    fastcgi.impersonate = 1



    ref. questions:




    • Setting permission for PHP (or I_USER [I'm not sure here...]) to connect to iisweb.vbs


    • Impersonate Domain User with Integrated Pipeline


    • https://serverfault.com/questions/313100/iis-forms-authentication-php-asp-net-server-side-login (didn't attempt but looks promising -- will attempt tomorrow)


    • PHP LDAP binding AD with the server's user account (doing ldap_bind() without setting credentials)





    Update 24-11-2018: The sysadmin gave me these information:



    config.md:



     <add name="ADConnectionString" connectionString="LDAP://spacelantern-central/DC=spacelantern,DC=com" />

    <membership defaultProvider="ADMembershipProvider">
    <providers>
    <clear />
    <add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" />
    </providers>
    </membership>


    code.md:



    if (Membership.ValidateUser("userid", "password"))
    {
    //
    }









    share|improve this question



























      0












      0








      0








      I have a PHP website running as an App on IIS.



      The app is using a specific Identity that runs all php-cgi.exe processes under NetworkService user that has access to the AD server.



      There's also another .NET app in the IIS where it's using the same identity and can log into the AD using the class System.Web.Security.FormsAuthentication and uses Forms Authentication in the Authentication settings in IIS. I tried copying the settings over but to no avail.



      The .NET code:



      ...
      using System.Web.Security.Membership.ValidateUser;
      ...

      public ActionResult Login(Login model, string route)
      {
      if (Membership.ValidateUser(model.Username, model.Password)) {
      FormsAuthentication.SetAuthCookie(model.Username);
      return Redirect(route);
      }

      return RedirectHome();
      }


      My code running on IIS with PHP CGI, impersonate is on on IIS level and php.ini level:



      public function login()
      {
      $ldapHost = 'ldap://spacemudd-ad';

      // PHP should use server's (iis) credentials when connecting. (impersonate)
      $connection = ldap_connect($ldapHost);

      // This always fails.
      //
      // "ldap_bind(): Unable to bind to server: Can't contact LDAP server"
      //
      // I believe due to the php-cgi.exe not sending the request
      // to the AD server through the IdentityPool's user (NetworkService)
      // even though in the TaskManager, the php-cgi.exe shows the owner is
      // NetworkService?
      //
      $ldapBind = ldap_bind($connection);

      // TODO: Search the AD directory for the user to be authenticated.
      }


      php.ini configuration:



      fastcgi.impersonate = 1



      ref. questions:




      • Setting permission for PHP (or I_USER [I'm not sure here...]) to connect to iisweb.vbs


      • Impersonate Domain User with Integrated Pipeline


      • https://serverfault.com/questions/313100/iis-forms-authentication-php-asp-net-server-side-login (didn't attempt but looks promising -- will attempt tomorrow)


      • PHP LDAP binding AD with the server's user account (doing ldap_bind() without setting credentials)





      Update 24-11-2018: The sysadmin gave me these information:



      config.md:



       <add name="ADConnectionString" connectionString="LDAP://spacelantern-central/DC=spacelantern,DC=com" />

      <membership defaultProvider="ADMembershipProvider">
      <providers>
      <clear />
      <add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" />
      </providers>
      </membership>


      code.md:



      if (Membership.ValidateUser("userid", "password"))
      {
      //
      }









      share|improve this question
















      I have a PHP website running as an App on IIS.



      The app is using a specific Identity that runs all php-cgi.exe processes under NetworkService user that has access to the AD server.



      There's also another .NET app in the IIS where it's using the same identity and can log into the AD using the class System.Web.Security.FormsAuthentication and uses Forms Authentication in the Authentication settings in IIS. I tried copying the settings over but to no avail.



      The .NET code:



      ...
      using System.Web.Security.Membership.ValidateUser;
      ...

      public ActionResult Login(Login model, string route)
      {
      if (Membership.ValidateUser(model.Username, model.Password)) {
      FormsAuthentication.SetAuthCookie(model.Username);
      return Redirect(route);
      }

      return RedirectHome();
      }


      My code running on IIS with PHP CGI, impersonate is on on IIS level and php.ini level:



      public function login()
      {
      $ldapHost = 'ldap://spacemudd-ad';

      // PHP should use server's (iis) credentials when connecting. (impersonate)
      $connection = ldap_connect($ldapHost);

      // This always fails.
      //
      // "ldap_bind(): Unable to bind to server: Can't contact LDAP server"
      //
      // I believe due to the php-cgi.exe not sending the request
      // to the AD server through the IdentityPool's user (NetworkService)
      // even though in the TaskManager, the php-cgi.exe shows the owner is
      // NetworkService?
      //
      $ldapBind = ldap_bind($connection);

      // TODO: Search the AD directory for the user to be authenticated.
      }


      php.ini configuration:



      fastcgi.impersonate = 1



      ref. questions:




      • Setting permission for PHP (or I_USER [I'm not sure here...]) to connect to iisweb.vbs


      • Impersonate Domain User with Integrated Pipeline


      • https://serverfault.com/questions/313100/iis-forms-authentication-php-asp-net-server-side-login (didn't attempt but looks promising -- will attempt tomorrow)


      • PHP LDAP binding AD with the server's user account (doing ldap_bind() without setting credentials)





      Update 24-11-2018: The sysadmin gave me these information:



      config.md:



       <add name="ADConnectionString" connectionString="LDAP://spacelantern-central/DC=spacelantern,DC=com" />

      <membership defaultProvider="ADMembershipProvider">
      <providers>
      <clear />
      <add name="ADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider" connectionStringName="ADConnectionString" attributeMapUsername="sAMAccountName" />
      </providers>
      </membership>


      code.md:



      if (Membership.ValidateUser("userid", "password"))
      {
      //
      }






      php active-directory ldap windows-server-2012-r2






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 24 '18 at 7:42







      Shafiq al-Shaar

















      asked Nov 20 '18 at 12:01









      Shafiq al-ShaarShafiq al-Shaar

      816715




      816715
























          1 Answer
          1






          active

          oldest

          votes


















          0














          I suspect you have two problems. First, this:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldapPort);


          What is the value in $ldapPort? The name of that variable suggests that it contains the TCP port to connect to, but that is not what LDAP_OPT_PROTOCOL_VERSION is for.



          LDAP_OPT_PROTOCOL_VERSION is for the LDAP version to use when communicating. For AD, you can set it to 3, since AD supports LDAPv3:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3);


          Second, if you need to connect to a different port than the default (389), then you need to pass it in the call to ldap_connect:



          $connection = @ldap_connect($ldapHost, $ldapPort);





          share|improve this answer
























          • Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

            – heiglandreas
            Nov 21 '18 at 5:02











          • @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

            – Gabriel Luci
            Nov 21 '18 at 13:21











          • Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

            – heiglandreas
            Nov 21 '18 at 15:40













          • @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

            – Shafiq al-Shaar
            Nov 21 '18 at 21:00











          • ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

            – Gabriel Luci
            Nov 21 '18 at 21:58











          Your Answer






          StackExchange.ifUsing("editor", function () {
          StackExchange.using("externalEditor", function () {
          StackExchange.using("snippets", function () {
          StackExchange.snippets.init();
          });
          });
          }, "code-snippets");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "1"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53392584%2fusing-built-in-iis-ad-authentication-by-php-cgi-under-an-identitypool%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          I suspect you have two problems. First, this:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldapPort);


          What is the value in $ldapPort? The name of that variable suggests that it contains the TCP port to connect to, but that is not what LDAP_OPT_PROTOCOL_VERSION is for.



          LDAP_OPT_PROTOCOL_VERSION is for the LDAP version to use when communicating. For AD, you can set it to 3, since AD supports LDAPv3:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3);


          Second, if you need to connect to a different port than the default (389), then you need to pass it in the call to ldap_connect:



          $connection = @ldap_connect($ldapHost, $ldapPort);





          share|improve this answer
























          • Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

            – heiglandreas
            Nov 21 '18 at 5:02











          • @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

            – Gabriel Luci
            Nov 21 '18 at 13:21











          • Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

            – heiglandreas
            Nov 21 '18 at 15:40













          • @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

            – Shafiq al-Shaar
            Nov 21 '18 at 21:00











          • ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

            – Gabriel Luci
            Nov 21 '18 at 21:58
















          0














          I suspect you have two problems. First, this:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldapPort);


          What is the value in $ldapPort? The name of that variable suggests that it contains the TCP port to connect to, but that is not what LDAP_OPT_PROTOCOL_VERSION is for.



          LDAP_OPT_PROTOCOL_VERSION is for the LDAP version to use when communicating. For AD, you can set it to 3, since AD supports LDAPv3:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3);


          Second, if you need to connect to a different port than the default (389), then you need to pass it in the call to ldap_connect:



          $connection = @ldap_connect($ldapHost, $ldapPort);





          share|improve this answer
























          • Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

            – heiglandreas
            Nov 21 '18 at 5:02











          • @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

            – Gabriel Luci
            Nov 21 '18 at 13:21











          • Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

            – heiglandreas
            Nov 21 '18 at 15:40













          • @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

            – Shafiq al-Shaar
            Nov 21 '18 at 21:00











          • ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

            – Gabriel Luci
            Nov 21 '18 at 21:58














          0












          0








          0







          I suspect you have two problems. First, this:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldapPort);


          What is the value in $ldapPort? The name of that variable suggests that it contains the TCP port to connect to, but that is not what LDAP_OPT_PROTOCOL_VERSION is for.



          LDAP_OPT_PROTOCOL_VERSION is for the LDAP version to use when communicating. For AD, you can set it to 3, since AD supports LDAPv3:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3);


          Second, if you need to connect to a different port than the default (389), then you need to pass it in the call to ldap_connect:



          $connection = @ldap_connect($ldapHost, $ldapPort);





          share|improve this answer













          I suspect you have two problems. First, this:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldapPort);


          What is the value in $ldapPort? The name of that variable suggests that it contains the TCP port to connect to, but that is not what LDAP_OPT_PROTOCOL_VERSION is for.



          LDAP_OPT_PROTOCOL_VERSION is for the LDAP version to use when communicating. For AD, you can set it to 3, since AD supports LDAPv3:



          ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, 3);


          Second, if you need to connect to a different port than the default (389), then you need to pass it in the call to ldap_connect:



          $connection = @ldap_connect($ldapHost, $ldapPort);






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 20 '18 at 16:38









          Gabriel LuciGabriel Luci

          10.6k11424




          10.6k11424













          • Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

            – heiglandreas
            Nov 21 '18 at 5:02











          • @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

            – Gabriel Luci
            Nov 21 '18 at 13:21











          • Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

            – heiglandreas
            Nov 21 '18 at 15:40













          • @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

            – Shafiq al-Shaar
            Nov 21 '18 at 21:00











          • ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

            – Gabriel Luci
            Nov 21 '18 at 21:58



















          • Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

            – heiglandreas
            Nov 21 '18 at 5:02











          • @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

            – Gabriel Luci
            Nov 21 '18 at 13:21











          • Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

            – heiglandreas
            Nov 21 '18 at 15:40













          • @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

            – Shafiq al-Shaar
            Nov 21 '18 at 21:00











          • ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

            – Gabriel Luci
            Nov 21 '18 at 21:58

















          Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

          – heiglandreas
          Nov 21 '18 at 5:02





          Actually using the port-parameter in ldap_connect is deprecated for quite a while. You should use an URI as the only parameter to ldap_connect like this: "ldap://ldap.example.com:port". That's the only way to also specify usage of ldaps-protocol

          – heiglandreas
          Nov 21 '18 at 5:02













          @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

          – Gabriel Luci
          Nov 21 '18 at 13:21





          @heiglandreas The documentation doesn't say anything about it being deprecated. Although it does say that the port is "Not used when using LDAP URIs". So you can either do ldap_connect($ldapHost, $ldapPort) or ldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort).

          – Gabriel Luci
          Nov 21 '18 at 13:21













          Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

          – heiglandreas
          Nov 21 '18 at 15:40







          Internally ldap_connect creates an LDAP_URI when only host and port are provided. So when you provide a host and a port only that involves more work to be done. It's only still available to be backwards compatible. But you are right, the documentation should be adapted!

          – heiglandreas
          Nov 21 '18 at 15:40















          @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

          – Shafiq al-Shaar
          Nov 21 '18 at 21:00





          @GabrielLuci Hey Gabriel, Thank you for the reply. I tinkered a lot with the issue today. I updated my question as I have now better understood my situation.

          – Shafiq al-Shaar
          Nov 21 '18 at 21:00













          ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

          – Gabriel Luci
          Nov 21 '18 at 21:58





          ldap_bind() does not use impersonation when connecting. The documentation says "The bind_rdn can also be left empty for an anonymous bind." So it's trying to connect anonymously, and AD is saying no.

          – Gabriel Luci
          Nov 21 '18 at 21:58


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53392584%2fusing-built-in-iis-ad-authentication-by-php-cgi-under-an-identitypool%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          MongoDB - Not Authorized To Execute Command

          How to fix TextFormField cause rebuild widget in Flutter

          in spring boot 2.1 many test slices are not allowed anymore due to multiple @BootstrapWith