Last post Jul 21, 2009 11:51 AM by bobMcclain
Mar 03, 2006 06:34 PM|joshlrogers|LINK
<add name="ADConnectionString" connectionString="LDAP://10.1.1.1/OU=Edison Users,DC=nashville,DC=edison,DC=com"/>
<add name="MyADMembershipProvider" type="System.Web.Security.ActiveDirectoryMembershipProvider,
PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString" connectionUsername="edison\jrogers" connectionPassword="password" attributeMapUsername="sAMAccountName" enableSearchMethods="true" connectionProtection="None"/>
Mar 08, 2006 05:03 PM|dunnry|LINK
Mar 08, 2006 09:07 PM|joshlrogers|LINK
Mar 13, 2006 01:39 PM|joshlrogers|LINK
Mar 13, 2006 02:35 PM|dunnry|LINK
Aug 14, 2006 11:18 AM|joshlrogers|LINK
I have ran a packet sniffer and I am finding that it is timing out on a request of:
Command: SAM LOGON request from client (0x12)
Request Count: 0
Unicode Computer Name: CYCLOPS
Mailslot Name: \MAILSLOT\NET\GETDC830
I see four of these and all together these requests take up about 22 seconds then it proceeds on....I don't get a response from the DC to these requests so I can't further analyze....could you possibly point me in the right direction? I am guessing the
empty username is the problem...but I don't know exactly what this request is....
Aug 14, 2006 04:07 PM|dunnry|LINK
Aug 21, 2006 12:30 AM|bdesmond|LINK
Do you have access to the DC?
What's CPU and Disk I/O look like at this point? Is the DC being trashed by other applications?
Any relevant events? AD will log events for long running queries.
Try doing an ldap bind (just use ldp) from the problem server - are you seeing the same results?
Aug 28, 2006 09:06 AM|joshlrogers|LINK
I do have access to both the Primary and Secondary DC and neither one have any significant CPU, I/O, or Memory usage.
There are no events, and using LDP does not cause the same authentication issue that was noted above. It is only when there is an attempted authentication using the ActiveDirectoryMembershipProvider.
I think this pretty much has to be an issue with either the provider or the login control....
Thanks for your help,
Oct 27, 2006 09:50 AM|joshlrogers|LINK
I would really like to bring this up again.....I still have not had this issue solved and we are going on almost a year that that has been happening. I am still seeing the same issues in Ethereal as I have mentioned above.
I have gone so far as to remove all other possible computers from the switch to where it is just one client computer and one DC and it still provided the same issue.
Could someone please provide me with a means in which to solve this problem, I am catching a lot of flack for having a login screen that can take up to 30 seconds.
Oct 31, 2006 05:19 PM|synistyr|LINK
Did you ever find out why this was happening and how to fix it? I'm having the same issue. When I debug/run my application locally, the LDAP queries run quickly and bring back the AD information quickly, but when I deploy my application to the web server,
searches take FOREVER.. (something that takes 2-3secods to execute locally takes 2+ minutes to run on the webserver.
Nov 01, 2006 08:53 AM|joshlrogers|LINK
I have not found out why this is happening. As of right now it makes absolutely no sense. As I stated before I attempted removing all machines from the network except for the IIS server and the DC and I still had the same issue. I now I have two DC working
load balanced and there is no improvement. I would very much like to get this figured out, but I have not received much support on it as of yet...
Nov 01, 2006 10:15 AM|joshlrogers|LINK
Nov 17, 2006 06:54 AM|Airstriker|LINK
I've been playing with this annoying thing a bit too and finally found a simple solution. It has something to do with DNS setting in AD. My problem was i don't have rights to change anything there (in AD) so I found something really simple and working great.
Just except using connection string like this:
use something like this:
(use IP adress and not domain)
After setting this I can login not in 2-3 minutes but in just few seconds !!!
Have fun ;)
Nov 28, 2006 05:07 PM|synistyr|LINK
Well.. it now takes 1+ minute instead of 2+ minutes. Still not quite there yet... argh.
Nov 28, 2006 05:11 PM|joshlrogers|LINK
Changing between the domain name and the ip address served no benefit for me unfortunately. I truly wish we could get Microsoft support on this, I do not want to have to pay the money for the tech support (which I think is ridiculous anyways). This is
obviously an issue, maybe not wide spread but it is effecting some of us.
Nov 28, 2006 05:20 PM|synistyr|LINK
No wait.. strike that.. it only took 1+ minutes for the first queries.. which now it runs at normal speeds!
But I can't get the description of the group. One step forward, two steps back.
Nov 28, 2006 06:27 PM|joshlrogers|LINK
Wait until you session expires.....
My users will connect and the first one will take 30seconds then the subsequent ones can connect right away. Give it about 2-3 minutes and no one has logged in the next person will have to wait the 30seconds to log in again and so on and so on.
Dec 04, 2006 09:00 AM|denloof|LINK
Same problem here, first one takes some time after that all connects are normal.
Wait a few minutes and the whole thing starts all over....
Dec 04, 2006 10:51 AM|joshlrogers|LINK
Aye, I am hoping that this thread continually being bumped up to the top by other people having issues other than I will get the attention of someone that can help. My users have been dealing with this now for almost a year and I can't seem to get a response.
Dec 04, 2006 12:53 PM|denloof|LINK
Could you try this:
- both on the site and on the app-pool in IIS, instead of the default account try to let them run under a domain account. Remember to make the account a member of the local IIS_WPG group or else you can get errors (or at least I get those).
It's a bit to soon to tell but I think the problem is in the first contact. If that is initiated with the default local account something's going wrong. After that it seems to switch to another communication option (hence the smooth opperation after the
first long period). After some time I gues the pipe is reset/dropped and everything starts all over again. I bet there are some people around here that could explain this better...
At least this seems to help with me.
Dec 19, 2006 11:25 AM|Speeder|LINK
We're having the same problem (SBS 2003, everything else AD related is fast, no eventviewer codes, maybe 100 AD accounts). Using IP instead of a name didn't help.
Dec 21, 2006 10:43 AM|denloof|LINK
Are you logging security events?
Also try to look at the following: on the webserver that needs to authenticate go to dos-prompt and type: netstat
It should give you no references to the DC you are trying to authenticate against (in that case try to logon in the website) or it should give you several items that metion your server. When performace was slow on my webserver I only got 1 item in the list
when a connection was made. After switching to dns-name and the account changes (listed above) I have several items in the list when using netstat.
In the security logs on the DC (not webserver) you should see several items around the time the first connection is made. When somethings wrong you can see why it takes so long because it retries after 30 seconds or so. This happens till some threshold is
reached (this is not quit clear to me) after that you can see the loggin succeeds.
Try checking the dns settings also because with ip add, in web.config, it didn't work in my case. Only after switching to dns is perfermance good.
Hope this helps
Feb 05, 2007 01:58 PM|mike_beeman|LINK
this is my first time posting, so please forgive lack of etiquette if I have any......
I had a similar problem and was able to fix it with the dns setting mentioned above. We figure out why this happens if this helps anyone. In our domain we have internal dns servers and external, and when we placed our old named configuration file in the
internal network speeds were fine. When we placed it on the web server it took about 60 seconds to log in. After adjusting the config to the proper ip address this solved the problem. Alternately, you could try to edit your hosts file to point to the proper
DC. I hope this helps.....
Feb 08, 2007 03:18 PM|eraza|LINK
Just to chime in that I've had the same problems.
1) I built an ldap query using the handy little win2k3 admin pack, which lets you create a query and then have the text of what you did. When I run it in the "Users & Computers" thingy, my request takes a fraction of a second.
2) I take the same code, and drop it into a DirectorySearcher(), doing a for/each to build a collection, and it takes about two minutes and beats the tar out of my web server's processor.
Haven't tried going against an IP instead of the name yet, although I don't understand why that would matter a lot since (I would hope) that when I send my request over that's the end of the conversation with the domain controller; maybe the
reference variable is holding a reference all the way back to the LDAP source? :shudder:
So like everyone, I'm not sure why this is causing so much of a headache, and if I come up with anything, I'll of course post it.
Jan 20, 2008 11:08 PM|shalack94|LINK
I had the same problem. The reason is that the application domain times out every 20 mins if there is no activity, the first request after the timeout can force a recompile and reload of cache. Changing some settings in the machine.config file will solve
the problem; unfortunately for me my hosting provider would not allow me to make this change and I do not have enough traffic to keep the cache from timing out. I found this utility to be useful.
Essentially it "Pings" my home page every few mins so the application domain does not time out. The utility can also be configured to ping more than one page so that auxiliary pages are fast too.
Feb 13, 2008 05:27 AM|gxxg|LINK
Digging out this old post just in case there are new findings. Got the same problem with our project. Hardware and network should not be the cause as AD operations in code does not suffer from the slow response at all. My guess is that when the web app starts
the AD membership provider needs to negociate with the AD server to establish some sort of channel, which takes some time to finish. If that is the case, is there any way to speed it up?
Feb 13, 2008 01:48 PM|vane151|LINK
Please, I need some help in here... I have the same issue and it's driving me crazy.
Login takes about 20-30 sec, if you logout and login again it will be really fast. Then wait for about 30 min, and login takes 20-30 sec again. I do not understand what is going on????
I have tried different ways of typing the LDAP connection string, and none of them worked.
LDAP://ServerIP/DC=domain,DC=com, this one takes about 20-30 sec
ldap://servername.domain.com/, this one takes about 40-50 sec
LDAP://servername/DC=domain,DC=com, this one takes about 40-50 sec
Any help would be appreciated
Apr 18, 2008 10:43 AM|PatrickRR|LINK
After struggling with this issue on production servers we found out the issue by running a trace. IIS was going to a VeriSign IP Address crl.VeriSign.com to pull an SSL Revocation list.
This would happen the first time a signed assembly was loaded by the IIS Worker Process. The second time you go to the page it was quick. If the assembly was unloaded and had to load again IIS would again call
crl.VeriSign.com to get the SSL Cert revocation list.
We were able to repeat this issue over and over again.
Microsoft has a hotfix, or .NET Framework SP1 plus a configuration setting change to stop IIS from going after the file from VeriSign.
Here are two helpful links.
Apr 18, 2008 12:41 PM|joshlrogers|LINK
Well I am thoroughly impressed....it is sad although that someone from Microsoft couldn't have chimed in with this. Well the program that I originally had the issue with I am not even working with that company anymore....it was just something they had to
deal with...unfortunate..I do thank you for the solution though and when I have the displeasure of dealing with this again I'll be referring to your solution!
Apr 28, 2008 09:37 AM|PatrickRR|LINK
I finally have this move to a QA Server and the sites now FLY! Finally!
If you have the .NET 2.0 SP1 installed just add the following to the machine.config (of course all sites will not check verisign any longer)
I tried to create an aspnet_wp.exe.config but it did not work. This code per other forums cannot be added to the web.config.
Jul 22, 2008 12:43 PM|dday515|LINK
I'm having this same issue - I've added the above code to no avail.
I'm running SBS 2003, if that makes a difference.
Does anyone have any other suggestions? its driving me (and my users) batty.
Jul 25, 2008 04:20 PM|joshuag|LINK
I'm having a similar problem, though the suggestions that were made haven't helped me yet. I run IIS6 on Windows 2003 Server with the .NET Framework 1 SP1 and .NET Framework 2 SP1.
My web applications connect to our LDAP server for login and password authentication, and I've narrowed down the single line of code that is causing the slowness.
DirectoryEntry entry =
entry.AuthenticationType = AuthenticationTypes.SecureSocketsLayer;
search.Filter = "(mail=" + email + ")";
SearchResult result = search.FindOne();
The "search.FindOne();" is taking 20 seconds every time someone logs in, whereas connecting to the LDAP server without SecureSocketsLayer is very fast. Does anyone have any thoughts on what is causing the slowness? I moved these applications from a Windows
2000 Server running IIS5 which wasn't slow at all.
Many thanks for any help you can give me, and please don't hesitate to ask questions if you need more details.
Jul 21, 2009 11:42 AM|bobMcclain|LINK
I'm having the same issue; I'm using the login control just like you. Have you had any progress on this?
Once the click login it takes 30 seconds
Jul 21, 2009 11:51 AM|bobMcclain|LINK
A little more detail to add is I'm using visual studio 2008; any help would be appreciated