Ressourcen für IT-Professionals >
Forenhomepage
>
Network Access Protection
>
NAP - 2 Minute Logon Delay
NAP - 2 Minute Logon Delay
- I need to know how to get my NAP deployment to authenticate faster. Often when people log in in the morning if they hit CNTL-ALT-DELETE and attempt to log in the moment the computer comes up they get "no domain controller available" message. Right now they are considering removing NAP because of this as it just caused us a heck of a Monday morning problem. Eventually it will authenticate but it takes to long for the way people work. I'm doing dual authentication so I'm considering removing the MAC-based as it isn't needed as much. Also I use HP Switches and one of the settings is "aaa port-access authenticator <PORT> quiet-period 30" I know this setting has the EAP authentication delay 30 seconds between retries (which is most likely causing the delay). I just want to know what I should do to speed up the authentication process.
-Gunnar- Bearbeitetgunnarwb Montag, 26. Oktober 2009 17:10
Alle Antworten
- I've been doing research into this and what I've found is that the NAP authentication seems to be completed. I do a show vlan <ID> and I see that the offending workstation is in the correct VLAN, when I look on the NAP server I see that it has already authenticated, however the machine does not have an IP address. I see no errors on the DHCP server and have no idea why it takes so long. Eventually the IP is given to the workstation and the workstation logs in. So I guess the issue is that it takes a long time for an IP to be given to a NAP client.
- As an update to that last post I have removed DHCP as the cause, as I have setup static IPs and I have the same issue.
This thread seems to be my problem but setting up a guest (unauth) network did not change my issue, there continues to be a delay between getting on the VLAN and getting an IP.
http://social.technet.microsoft.com/Forums/en-US/winserverNAP/thread/ba2ce768-4ade-4e20-a7cc-9610c519fe4b/ - Also, I have found it this only happens on boot. If I remove the NIC Cable and plug it back in authentication happens in seconds. It has to be something on boot up causing this.
- Thanks for all the input! :P
Okay, I think I narrowed it down to the Windows Security Health Agent. What I've found is that this thing launches on boot EVENT ID 1002, and completes almost exactly 2 minutes later EVENT ID 1007. However, while this is running the computer cannot log on, it just sits there. I know the guys from Microsoft monitor this forum, can you give me any insight into how I can disable this from running. The source in Eventviewer is MSSHA but google doesn't give me anything on that search. I'm fairly confident this is the source of the problem once the event goes to 1007 and the thing completes it scan I can ping the machine, I'm guessing this service is keeping the NIC in a "limited" mode until it can verfy all is well. This is killing me right now, please help. - Hi gunnarwb,
I'm sorry it has taken a week to respond to you.
When a computer first starts up, there are two services that must start successfully before logon can fully occur in a NAP scenario. One provides identity information and the other provides health information. Without NAP, there is only the identity part.
The first service is the wired autoconfig service (dot3svc).
The next is the NAP agent service (napagent).
After NAP agent starts, you will see the MSSHA (aka the WSHA) do a health evaluation of the computer. If you use the WSHV to evaluate health of client computers, you must allow the WSHA to scan the client computer. The WSHA in turn depends on the Windows Security Center service (wscsvc).
Sometimes there is a problem whereby the first time a computer authenticates with 802.1X, it is considered non NAP-capable because the NAP agent service has not yet started. Then, after the NAP agent service starts the computer will re-authenticate. This might not be happening in your case if the port is in a wait state, but could this be occuring for the second authentication attempt?
If you disable NAP agent, you will make all computers non NAP-capable, so you don't want to do this. It sounds like you are using the WSHV also, so you don't want to disable Security Center.
Please check and see if the computer is making multiple authentication attempts, the first being non NAP-capable and the second being compliant or noncompliant. If there are multiple attempts, one solution is to make Dot3svc dependent on napagent via the registry. This can be done by adding napagent to the DependOnService value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\dot3svc. This will make 802.1X authentication occur after NAP agent has fully started.
-Greg - Here is what I know. I disabled NAP Agent and that got rid of the MSSHA but that didn't solve my issue. I'm not using any health evaluator at this point (we plan to use this in the future but not now), for now all we are doing is taking computer X of group Y and putting it in VLAN Z. I'm doing computer authentication not user. It works perfectly, I can see it authenticate on the NPS Server, however after authentication completes there is a 2-minute delay. In the event log I saw that MSSHA was doing a scan, after disabling NAP Agent (authentication still worked) MSSHA went away but I would see that "Group Policy has successfully been applied" leading me to believe this is a Group Policy issue. SO I started disabling Group Policy and eventually found the GP that was causing a delay. I got so far as to narrow it down to one of three settings:
Download missing COM components - ENABLED
Enable dis quotes - DISABLED
Allow use of Offline files - DISABLED
I had to change all of those to Not Configured and the delay went away. This troubleshooting seems completely wrong to me. I turned on verbous logons and I can see the GP being applied after the 2-minute delay, so I have a difficult time blaming it on GP, yet I can get the delay to disappear when I disable policies that have nothing to do with NAP. The only thing that lines up is that a few weeks back (when this issue started) not only did I deploy NAP that week, it was also the biggest single release of updates in Microsoft History. Maybe one of the updates fudged something up.
I can tell you beyond a shadow of a doubt it does not authenticate twice, it authenticates once, and is put in the correct VLAN. I can do a show vlan XX and see that the port is in the correct VLAN, however the computer does not respond to pings for 2-minutes. I can repeat the issue on demand. And my GP fix is terpermental, it works sometimes but not all of the time, so I really don't call it a fix... not yet at least.
-Gunnar - I'm opening a case with Microsoft, I'll post my results, but I'm sure it will be awhile before we have them.
-Gunnar - Hey Gunnar... any headway on this? We've got issues similar to those that you describe. Can you provide an update/solution?
Thanks!
B - Wow, sorry for the delay on this. I do have an update. We believe it is caused by Group Policy. Narrowing it down to one policy has been very difficult. We believe the massive updates done in November must have triggered something that is causing this delay. Our NAP project has been put on hold until Microsoft can give us a resolution, unfortunately I can't open a case due to internal problems (I work for the government... need I say more.) So I'm stuck with a product that doesn't work, we have stopped all deployment of NAP due to this issue, I'm told come January I will be able to open the case, until then I'm spinning wheeling trying to track down what in GP could cause this. (I didn't set up the GP and it's a bit of a mess, so I've been working the past few weeks auditing the GP).
-Gunnar Hi,
This question is still not answered but has fallen off the first page of the forum so it may not be getting the attention needed.
Please let me know if there is any further information about this issue. I will also try to summarize the current question and get an answer if possible, or move the question to another forum if it is not appropriate for the NAP forum.
Greg Lindsay
