Using built-in IIS AD authentication by PHP CGI under an IdentityPool
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
add a comment |
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
add a comment |
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
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
php active-directory ldap windows-server-2012-r2
edited Nov 24 '18 at 7:42
Shafiq al-Shaar
asked Nov 20 '18 at 12:01
Shafiq al-ShaarShafiq al-Shaar
816715
816715
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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);
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 doldap_connect($ldapHost, $ldapPort)
orldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort)
.
– Gabriel Luci
Nov 21 '18 at 13:21
Internallyldap_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
|
show 8 more comments
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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);
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 doldap_connect($ldapHost, $ldapPort)
orldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort)
.
– Gabriel Luci
Nov 21 '18 at 13:21
Internallyldap_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
|
show 8 more comments
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);
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 doldap_connect($ldapHost, $ldapPort)
orldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort)
.
– Gabriel Luci
Nov 21 '18 at 13:21
Internallyldap_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
|
show 8 more comments
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);
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);
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 doldap_connect($ldapHost, $ldapPort)
orldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort)
.
– Gabriel Luci
Nov 21 '18 at 13:21
Internallyldap_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
|
show 8 more comments
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 doldap_connect($ldapHost, $ldapPort)
orldap_connect("LDAP://" . $ldapHost . ":" . $ldapPort)
.
– Gabriel Luci
Nov 21 '18 at 13:21
Internallyldap_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
|
show 8 more comments
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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