Authentication
This can also be a tricky one.
In most cases you will control the authentication passing the standard Username and Password in your connection.
If the accountyou are making an ldap call from is in one domain and you are making a call to another domain and there is not a trust between the domains your call will fail. You can get around this by having an account in that foreign domain and specifically telling it that the account making the call is in that domain. username: domain\username This way, trusts do not come into play and is a totally viable option. That is why I always use the domain\username approach, even if I am only hitting a single domain. If you just use username, the call will assume your account is in the domain you are querying. I have also seen it try to use the domain of the machine you are calling from if the domain is ommited. This can cause serious latency in your queries. There are also other strings you can pass for username such as user@domain, distinguished name, etc but I prefer to stick with domain\username since most of the domains I have queried support it.
If you do not pass the credentials the call will use whatever account is making the call. In the case of of a web server, that call is being made by a non-authenticated application pool so it will die every time. You never want to assign an application pool to an account with domain permissions, that is simply wrong.
If you are storing the account and password on a web site you must insure that the data you are storing is strongly encrypted and you never want to save it in plain text in the web.config.. just like your SQL connections right?
Once you have the account and password for your bind connection, you are good.
You can also use passthru authentication allowing the user making connection's permissions to flow through to the ldap query. This means that the users rights will apply. I have seen this being problematic due to double hop authentication... meaning the client creds pass thru the web server to the domain controller.
In most cases you will control the authentication passing the standard Username and Password in your connection.
If the accountyou are making an ldap call from is in one domain and you are making a call to another domain and there is not a trust between the domains your call will fail. You can get around this by having an account in that foreign domain and specifically telling it that the account making the call is in that domain. username: domain\username This way, trusts do not come into play and is a totally viable option. That is why I always use the domain\username approach, even if I am only hitting a single domain. If you just use username, the call will assume your account is in the domain you are querying. I have also seen it try to use the domain of the machine you are calling from if the domain is ommited. This can cause serious latency in your queries. There are also other strings you can pass for username such as user@domain, distinguished name, etc but I prefer to stick with domain\username since most of the domains I have queried support it.
If you do not pass the credentials the call will use whatever account is making the call. In the case of of a web server, that call is being made by a non-authenticated application pool so it will die every time. You never want to assign an application pool to an account with domain permissions, that is simply wrong.
If you are storing the account and password on a web site you must insure that the data you are storing is strongly encrypted and you never want to save it in plain text in the web.config.. just like your SQL connections right?
Once you have the account and password for your bind connection, you are good.
You can also use passthru authentication allowing the user making connection's permissions to flow through to the ldap query. This means that the users rights will apply. I have seen this being problematic due to double hop authentication... meaning the client creds pass thru the web server to the domain controller.
- Log in to post comments
