|
Home > Archive > Radius Server > September 2006 > 802.1X/EAP authentication issue with XP client
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
802.1X/EAP authentication issue with XP client
|
|
|
| Hi..
I'm hoping someone can give me an idea about where to look next with this
issue!
Details below-->
Thanks!
Joe
I've got 17 XP clients authenticating fine using computer certificates and
EAP/802.1X with a 3Com switch and IAS. One client, same scenario, is not
getting a successful authentication. I don't see anything I've been able to
identify as bad in the IASSAM or RASTLS traces. Also, there is nothing
logged in the IAS or system event logs. I see a UDP Access-Request packet
going from the client to IAS.. and an unkown RPC message type being returned.
The strange thing with this client is that it had similar authentication
results when EAP was first implemented, and after removing (revoking) its
certificate and reissuing a new machine certificate it successfully
authenticated. After a few days, the event log shows that it successfully
authenticated this morning, but at some point (it may have been rebooted) it
came to be in its current state.
This is from IASSAM on the IAS server:
[1212] 13:14:20:335: NT-SAM Names handler received request with user
identity host/nbmachine.domain.com.
[1212] 13:14:20:351: Successfully cracked username.
[1212] 13:14:20:351: SAM-Account-Name is "NBDOMAIN\NBMACHINE$".
[1212] 13:14:20:351: NT-SAM Authentication handler received request for
NBDOMAIN\NBMACHINE$.
[1212] 13:14:20:351: No SAM credentials found. Checking account restrictions
and computing groups manually.
[1212] 13:14:20:351: Sending LDAP search to domain.com.
[1212] 13:14:20:398: Successfully processed account.
[1212] 13:14:20:398: NT-SAM User Authorization handler received request for
NBDOMAIN\NBMACHINE$.
[1212] 13:14:20:398: Using native-mode dial-in parameters.
[1212] 13:14:20:398: Sending LDAP search to domain.com.
[1212] 13:14:20:398: Successfully retrieved per-user attributes.
[1212] 13:14:20:398: NT-SAM EAP handler received request.
[1212] 13:14:20:398: No State attribute present. Creating new session.
[1212] 13:14:20:398: Successfully created new session for user
NBDOMAIN\NBMACHINE$.
[1212] 13:14:20:398: Setting max. packet length to 1020.
[1212] 13:14:20:398: Processing output from EAP DLL.
[1212] 13:14:20:398: Inserting outbound EAP-Message of length 6.
[1212] 13:14:20:398: Issuing Access-Challenge.
This is from RASTLS on the IAS server:
[1212] 13:14:20:398:
[1212] 13:14:20:398: EapTlsBegin(NBDOMAIN\NBMACHINE$)
[1212] 13:14:20:398: State change to Initial
[1212] 13:14:20:398: MaxTLSMessageLength is now 16384
[1212] 13:14:20:398: CRYPT_E_NO_REVOCATION_CHECK will not be ignored
[1212] 13:14:20:398: CRYPT_E_REVOCATION_OFFLINE will be ignored
[1212] 13:14:20:398: The root cert will not be checked for revocation
[1212] 13:14:20:398: The cert will be checked for revocation
[1212] 13:14:20:398:
[1212] 13:14:20:398: EapTlsMakeMessage(NBDOMAIN\NBMACHINE$)
[1212] 13:14:20:398: >> Received Response (Code: 2) packet: Id: 0, Length:
45, Type: 0, TLS blob length: 0. Flags:
[1212] 13:14:20:398: EapTlsSMakeMessage
[1212] 13:14:20:398: EapTlsReset
[1212] 13:14:20:398: State change to Initial
[1212] 13:14:20:398: GetCredentials
[1212] 13:14:20:398: Flag is Server and Store is local Machine
[1212] 13:14:20:398: GetCachedCredentials
[1212] 13:14:20:398: GetCachedCredentials: Using cached credentials.
[1212] 13:14:20:398: BuildPacket
[1212] 13:14:20:398: << Sending Request (Code: 1) packet: Id: 1, Length: 6,
Type: 13, TLS blob length: 0. Flags: S
[1212] 13:14:20:398: State change to SentStart
[1212] 13:14:20:398: EapTlsEnd
[1212] 13:14:20:398: EapTlsEnd(NBDOMAIN\NBMACHINE$)
This is a piece of the UDP packet returned from IAS.. the only response to
the client:
RPC message type 0x1DEC3B9B
00000020 1D EC ..
00000030 3B 9B ;.
| |
| James McIllece [MS] 2006-09-05, 7:43 pm |
| =?Utf-8?B?am9lQQ==?= <joeA@discussions.microsoft.com> wrote in
news:A20AEA20-CE29-4484-8F1C-166DFE268225@microsoft.com:
> Hi..
>
> I'm hoping someone can give me an idea about where to look next with
> this issue!
> Details below-->
>
> Thanks!
> Joe
>
> I've got 17 XP clients authenticating fine using computer certificates
> and EAP/802.1X with a 3Com switch and IAS. One client, same scenario,
> is not getting a successful authentication. I don't see anything I've
> been able to identify as bad in the IASSAM or RASTLS traces. Also,
> there is nothing logged in the IAS or system event logs. I see a UDP
> Access-Request packet going from the client to IAS.. and an unkown RPC
> message type being returned.
>
> The strange thing with this client is that it had similar
> authentication results when EAP was first implemented, and after
> removing (revoking) its certificate and reissuing a new machine
> certificate it successfully authenticated. After a few days, the
> event log shows that it successfully authenticated this morning, but
> at some point (it may have been rebooted) it came to be in its current
> state.
>
> snip <
>
Hi Joe --
I forwarded your question to the product team, and this is the response I
received:
"In order to get the full picture, we need to see the full set of logs from
the IAS server as well as netsh trace logs from the client. It appears that
the IAS server is responding with the intention to use EAP-TLS, but then
immediately resets (in the same millisecond). It is possible that the
client sent a negotiation for an unsupported EAP method which was discarded
silently. At any rate, it appears to be a client-side issue especially
since other clients are authenticating successfully. Please request netsh
logs from the failing client as well."
So please email your logs to me at wsdocs@microsoft.com and I will forward
them to the appropriate folks for analysis.
Thanks --
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
| James McIllece [MS] 2006-09-05, 7:43 pm |
| "James McIllece [MS]" <jamesmci@online.microsoft.com> wrote in
news:Xns983596AC6D711jamesmcionlinemicro
s@207.46.248.16:
> =?Utf-8?B?am9lQQ==?= <joeA@discussions.microsoft.com> wrote in
> news:A20AEA20-CE29-4484-8F1C-166DFE268225@microsoft.com:
>
>
> Hi Joe --
>
> I forwarded your question to the product team, and this is the
> response I received:
>
> "In order to get the full picture, we need to see the full set of logs
> from the IAS server as well as netsh trace logs from the client. It
> appears that the IAS server is responding with the intention to use
> EAP-TLS, but then immediately resets (in the same millisecond). It is
> possible that the client sent a negotiation for an unsupported EAP
> method which was discarded silently. At any rate, it appears to be a
> client-side issue especially since other clients are authenticating
> successfully. Please request netsh logs from the failing client as
> well."
>
> So please email your logs to me at wsdocs@microsoft.com and I will
> forward them to the appropriate folks for analysis.
>
> Thanks --
>
>
>
Another team member added the following info: "...something is happening
overtime to that certificate that renders it unusable. It might be some
sort of unhealthy growth in the Radius packet. Not sure. Modifying the
framed MTU might help in this issue. Lowering it a little bit might just do
the trick."
For information on changing the framed MTU, see the IAS Operations Guide at
http://www.microsoft.com/downloads/...=27c432bf-5ed0-
4763-8909-36e7c310ae3c&displaylang=en
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
|
| I zipped up and emailed the workstation and server netsh logs as requested.
I also tried adjusting the IAS remote access policy framed MTU param to a
value of 1340 as suggested in IASOpsGuide. EAP authentication is still
failing, although I see a slight difference in the IASSAM log:
[2532] 14:45:56:241: Setting max. packet length to 1020.
[2532] 14:45:56:241: Setting max. packet length to 1340.
So it looks like I adjusted it up instead of down! This is a LAN though,
and looking at the traffic I'm not seeing fragmentation, and all packets are
being reported as < 512 octets in size.
- Joe
"James McIllece [MS]" wrote:
> "James McIllece [MS]" <jamesmci@online.microsoft.com> wrote in
> news:Xns983596AC6D711jamesmcionlinemicro
s@207.46.248.16:
>
>
> Another team member added the following info: "...something is happening
> overtime to that certificate that renders it unusable. It might be some
> sort of unhealthy growth in the Radius packet. Not sure. Modifying the
> framed MTU might help in this issue. Lowering it a little bit might just do
> the trick."
>
> For information on changing the framed MTU, see the IAS Operations Guide at
> http://www.microsoft.com/downloads/...=27c432bf-5ed0-
> 4763-8909-36e7c310ae3c&displaylang=en
>
>
> --
> James McIllece, Microsoft
>
> Please do not send email directly to this alias. This is my online account
> name for newsgroup participation only.
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
| |
| James McIllece [MS] 2006-09-07, 7:44 pm |
| =?Utf-8?B?am9lQQ==?= <joeA@discussions.microsoft.com> wrote in
news:471A486C-D1B1-4B64-8C4C-974B6109E2A7@microsoft.com:
> I zipped up and emailed the workstation and server netsh logs as
> requested.
>
> I also tried adjusting the IAS remote access policy framed MTU param
> to a value of 1340 as suggested in IASOpsGuide. EAP authentication is
> still failing, although I see a slight difference in the IASSAM log:
> [2532] 14:45:56:241: Setting max. packet length to 1020.
> [2532] 14:45:56:241: Setting max. packet length to 1340.
> So it looks like I adjusted it up instead of down! This is a LAN
> though, and looking at the traffic I'm not seeing fragmentation, and
> all packets are being reported as < 512 octets in size.
>
> - Joe
>
>
> "James McIllece [MS]" wrote:
>
>
OK thanks Joe. I'll get back to you.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
| James McIllece [MS] 2006-09-07, 7:44 pm |
| >snip<
Hi Joe --
We have agreement that the problem is one of two things -- either the cert
was manually moved in the cert store, which caused the private key to
become disassociated from the cert, or the permissions on the private key
are incorrect, which means that the system itself cannot access the private
key.
If the issue is the first one, you can simply reissue the cert and specify
the machine store (called Local Computer certificate store in the UI) for
storage. In the future if you need to move a cert, make sure you export and
then import the cert rather than using drag and drop in the UI. Drag and
drop breaks the cert.
If the issue is that the permissions are incorrect there are two approaches
to take:
1. Go to the properties of "%systemroot%\Documents and Settings\All Users"
and set the permission for System and Administrators to Full Control. Make
sure this replicates down to all subfolders.
2. (A more specific approach) Locate the "%Userprofile%\Application
Data\Microsoft\Crypto\RSA\<User SID>" for the user logged on. Set the
permissions for the System and Administrators to Full Control. Then locate
the "%Userprofile%\Application
Data\Microsoft\SystemCertificates\My\Cer
tificates" for the user logged on.
Set the permissions for the System and Administrators to Full Control.
See KB 309408 for more information.
HTH, let me know how it goes, if you will.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
| |
|
| Hi James,
After an initial inspection, it seems that neither scenario that you
described exists.
The current machine certificate was installed using the Request New
Certificate wizard via the certificates mmc UI (done with domain/user
local/admin privileges). The original machine certificate was the result of
machine autoenrollment. Either way.. the certificate landed directly in the
Personal\Certificates branch of the Local Computer store.
Re file permissions... all met the levels you described as necessary.
I'll read the article on the DPAPI.. based on the errorlog it does look like
the answer is related to that.. the authentication mechanism trying to get
the cert/token et al.
Thanks very much!
Joe
"James McIllece [MS]" wrote:
>
> Hi Joe --
>
> We have agreement that the problem is one of two things -- either the cert
> was manually moved in the cert store, which caused the private key to
> become disassociated from the cert, or the permissions on the private key
> are incorrect, which means that the system itself cannot access the private
> key.
>
> If the issue is the first one, you can simply reissue the cert and specify
> the machine store (called Local Computer certificate store in the UI) for
> storage. In the future if you need to move a cert, make sure you export and
> then import the cert rather than using drag and drop in the UI. Drag and
> drop breaks the cert.
>
> If the issue is that the permissions are incorrect there are two approaches
> to take:
>
> 1. Go to the properties of "%systemroot%\Documents and Settings\All Users"
> and set the permission for System and Administrators to Full Control. Make
> sure this replicates down to all subfolders.
>
> 2. (A more specific approach) Locate the "%Userprofile%\Application
> Data\Microsoft\Crypto\RSA\<User SID>" for the user logged on. Set the
> permissions for the System and Administrators to Full Control. Then locate
> the "%Userprofile%\Application
> Data\Microsoft\SystemCertificates\My\Cer
tificates" for the user logged on.
> Set the permissions for the System and Administrators to Full Control.
>
> See KB 309408 for more information.
>
> HTH, let me know how it goes, if you will.
>
>
>
>
> --
> James McIllece, Microsoft
>
> Please do not send email directly to this alias. This is my online account
> name for newsgroup participation only.
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
| |
| James McIllece [MS] 2006-09-16, 1:42 pm |
| =?Utf-8?B?am9lQQ==?= <joeA@discussions.microsoft.com> wrote in
news:0EA13928-04CE-492C-BC63-1256B389ECC3@microsoft.com:
> Hi James,
>
> After an initial inspection, it seems that neither scenario that you
> described exists.
>
> The current machine certificate was installed using the Request New
> Certificate wizard via the certificates mmc UI (done with domain/user
> local/admin privileges). The original machine certificate was the
> result of machine autoenrollment. Either way.. the certificate landed
> directly in the Personal\Certificates branch of the Local Computer
> store.
>
> Re file permissions... all met the levels you described as necessary.
>
> I'll read the article on the DPAPI.. based on the errorlog it does
> look like the answer is related to that.. the authentication mechanism
> trying to get the cert/token et al.
>
> Thanks very much!
> Joe
>
>
>
> "James McIllece [MS]" wrote:
>
>
Thanks for this info, Joe -- I will run it by the team and see if they have
any additional suggestions for you.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
|
|
|