Forum Replies Created
-
Posts
-
This is apparently not hardware specific, this occurs on 3040, 5070, 5470 and OptiPlex 3000 on 9.1.6108 only for re-authentication attempts. Any previous firmware this is working without issue. Firmware 9.1.2205 should be out soon, will test and report back. Dell engineering has a Jira ticket escalated to them for a bug report. Its as if the EAP services stops itself after the first authentication which you can see in the log file after successful EAP authentication it will enter and informational message:
- EAP Authentication state ‘completed’
- EAP Authentication state ‘disconnected’
- EAP Authentication state ‘inactive’
The ‘inactive’ is what makes me thing the process stopped but they should be able to find the delta in the code for EAP from 9.1.5067 to 9.1.6108 to understand what changed.
Maybe try the root certificate from the ISE and adjust “Select Install CA Certificate” to OFF
Not sure what the issue is but the errors seem to point to something in the certificate chain.
RE: 1) No I did not create a computer name in AD. Is that a requirement for EAP/TLS?
I’m not sure if its required for your environemnt, it is for mine. Our Cisco ISE server is setup to look at a specific AD group to see if the object SN is listed, if its listed and matches the certificate SN it passes 802.1x
When you do 802.1x enrollment in WMS under Privacy and Security do you have “Select Install CA Certificate” ON? Check with your network guys that the Cisco ISE is looking at the correct certificate chain and any intermediate certificates needed for the authentication process and that you have them installed. The error looks like there is an unsupported certificate.
Also make sure the time on the thin client is sync’d with whatever your internal time server is, if the time is off the certificates will be out of sync. I’ve seen that before too where time/date resets itself to sometime in 2012 and the certificates are at a time in the future and not valid.
Tried to edit my post and it timed out
In WMS
Under Privacy and Security>SCEP:
Common Name: Use $TN or $SN, don’t add .crt or .cer or .pfx
Under Network Configuration>Ethernet Settings>802.1x Authentication Settings
- Enable EAP Authentication: ON
- Validate Server: OFF
- Check Server: OFF
- Server Name: blank (empty)
- EAP Type: EAP-TLS (or whatever you use)
- Client Certificate Filename: scep_cert_$SN.crt
- Client Certificate Type: Machine
This is what works in my environment. What I’ve found is leaving the Common Name as $SN or $TN don’t designate a certificate type (pfx, crt, cer). My certificates import at SN.pfx or TN.pfx, but when I tell it to authenticate using the Client Certificate Filename it needs to be in the format of scep_cert_$SN.crt (or $TN) regardless that the imported cert is showing as SN.pfx (or $TN) in my list. I think this is a legacy bug from earlier version of ThinOS 9 when the certificate actually got imported with the common name scep_cert_$SN.crt
Try that and see if it works for you.
What happens when you close the port?
I understand the error messages, but try closing the port.
Also, I’m assuming you have an AD object created for $TN with the terminal name for Cisco ISE to authenticate against?
Silly question but I’m assuming you’re all running WMS 3.6.241 and under peripheral management you have “Manual Override” turned on so any modifications made by the user stick?
Has this ever worked for you in ThinOS 9 or is this the first time you’re trying? Since you’re using USB redirection for the printer can you install the printer drivers and software on your Windows session and does it detect the printer through USB?
While not related to your issue, 9.1.6108 also introduced freezing, choppiness with Zoom video while optimized (using the Zoom plug-in). My guess is it has to do with their introduction of the video optimization settings in ThinOS under peripherals, video and you can adjust and customize the video settings.
If you revert back to 9.1.5067 and change nothing else does the experience go away?
Let’s take ThinOS out of the equation. If you use the store URL on a Windows device on your corporate network and plug the URL into native Citrix Workspace App, what is the behavior?
After working with Marvin, before even plugging the URL into a ThinOS policy I tested the URL in native Citrix Workspace for Windows and Citrix Workspace for Linux; it did not work in either. That’s a Citrix issue and not a ThinOS issue so if any of you try the same, you need that to work first before it will work in ThinOS. If that doesn’t work for you, open a case with Citrix and they can assist with your Citrix policy.
Also did you update the bios to the latest for 9.1.6? I have a fleet of various bios versions and trying to get them all up to the latest.
@Wulfgari that’s a great practice and glad you’re doing that.
The only other thing I would suggest, because Dell will probably tell you to do it if you open a case; wipe the device from the BIOS, just kill everything, rebuild from the USB imaging tool. Obviously that’s not how you want to manage a fleet of devices that get this message and you’ve had 6 out of 30 devices get it, not a good start, but I have a feeling that’s what will be suggested if you open a case.
If it’s easily reproduced, turn on debug logging and export to USB, happy to help pick through logs, I weirdly have a love for root cause analysis and happy to help out.
One thing you can try is resetting to factory on the device and then in WMS do a full removal by selecting Unregister on the device and then when searching devices search devices by “Not Registered” value in WMS and select the device and choose Delete. This removes the WMS object and potentially any device level settings you may be unaware of.
When I run into oddities like this I do a device wipe and full removal from WMS. Some times device objects in the WMS database get corrupt and Deleting them fully from WMS before registering again can resolve the issue.
Usually the message means what it says. Is it getting the update but then giving that message? Are you WMS public cloud? In a recent WMS public cloud update they started enforcing the case sensitivity of the registration token. Meaning it has always been in the admin guide that the WMS group registration token needed capital and lower case and numeric characters. When you would register with the token it wasn’t always enforcing the specific upper and lower cases until recently.
Example would be to create the group in WMS you had to use a mix
xxxx-WTOS9_California1 would be valid
You could register the device previously by typing xxxx-wtos9_california1 and it didn’t care it would successfully check in to WMS.
Now when registering you have to type it exactly as the group token: xxxx-WTOS9_California1 or it fails to check in.
