Active Directory "Log on to" Authentication

What do the event logs have to say about it?  If you don't see any entries, enable failure logging in the security log..

The local event logs look normal, they show
Logon Type:      2
Logon Process:      User32  
Authentication Package:      Negotiate

I was hoping that the authentication type would be different for the restricted account than a non-restricted account but it's the same for both, whether we have it auto login or not.

I have noticed that when the machines autologin the authentication type is 11, which is cached interactive.  This could be part of the reason that it won't authenticate.  I've had other people tell me in the past that they've seen authentication issues when using cached credentials.  I might have to get Microsoft on the phone to see if they know of any reason the "LogOnTo" Setting in AD would prevent cached creds from authenticating.  I am going to try and restrict my credentials to a specific machine, manually log in (no cached), and then try to authenticate through the Radius server.  I will post what I find.  

A friend told me that this was a confusing post so I am going to re-word it.  I have a kiosk user account named bob, the bob user account is restricted to a kiosk OU named bob's OU.  We have locked the bob user account down to only log into the PC's in Bob's OU using the "LogOnTo" setting in Active Directory under the Account Tab for the user.  When the PC logs in automatically with the credentials set in the registry it gives the following logon type: 11 (cachedinteractive.) The user account will not authenticate to the DC through a Radius wireless setup unless the LogOnTo setting allows the bob user account to sign into all computers. Can anyone tell me why the LogOnTo is affected by these cachedinteractive credentials?  

you said its using wireless to connect?  The account may be logging on to the computer using the cached information, probably because its not connecting to the wireless network UNTIL the computer is logged on to.  By that time, its already logged on to the computer using the cached info and doesn't recognize a need to authenticate with the domain...maybe?

Thats right along my line of thinking.  A little more info, the Radius setup uses a user certificate to authenticate. Could you tell me why it wouldn't need to authenticate at that point?  Any time you establish a new connection, plug in a LAN line, it will at that time re-authenticate with the DC will it not?  Any command lines we can pass in a batch or vbscript to make the authentication re-process?

you'd think it would...but i just had an instance of a similar problem.  One of my users was trying to change their logon password when connected thru VPN. They log in using cached credentials, log in via vpn and change the password on the network.  When they log off the computer and log back in, it still continued to log in using the older cached password info instead of the newly created password. when they logged in via VPN, the new password was the one that worked.  and this continued until the user plugged it into the LAN back at the office.
As for a script to remedy that, i wouldn't know where to begin :P

how is the wireless connecting?  Is it set to automatically connect to that wireless network upon discovery?