- This topic has 8 replies, 2 voices, and was last updated 5 years, 6 months ago by
BATECH.
-
AuthorPosts
-
December 7, 2018 at 9:52 am #48347
Hello,
We deploy a broker with two TSE servers. At login time, this gives us a message for an “incorrect user or password”. (It opens the TSE session) If we enter the password a second time, we connect to the session.
Model : 3010
Version : 8.5_017
the configuration of the wyse :
AddCertificate=cert___.cer
AddCertificate=certbroker___.pfxVDIBroker=broker.domain.loc
ConnectionBroker=Microsoft RDCollections=My_COLLECTIONS
SignOn=yes
DomainList=”domain.loc”Exit=All
screen after the first login :
Even if we inform the user and the password in wnos, it’s the same thing.
Thank you for your help 🙂
December 9, 2018 at 1:05 pm #48355Do you point the client to the Broker or the RDSHWeb service? Try the latter.
CG
December 10, 2018 at 12:16 pm #48363Hello,
Thank you for your reply 🙂
I tried to edit in the configuration file:
VDIBroker = broker.ba.loc/RDWeb/
Without success, he can not even start the TSE session.However in the logs during the old configuration, I had an error:
negotiate failure 2
Will retry without SSL
x244 layer connect failure!
ERROR: connection failed!I continue my research on my side pending a possible suggestion/solution.
thanks you
December 11, 2018 at 11:50 am #48391Are you sure you have added all and correct certificates?
A .pfx is normally not needed for server authentication.CG
December 31, 2018 at 2:42 pm #48508Hello,
Which certificates should be generated exactly?
Only that of the broker? or in addition, the TSE servers?Only the broker’s certificate is generated at the moment.
thank you and a good end of year party 🙂
January 10, 2019 at 5:27 pm #48788Good evening,
I come back to you for my problem 🙁
Here is the list of certificates generated on the broker.the two certificates added to the wyse ftp on “cacert” :
Do you have a procedure for certificates with a broker that manages multiple servers TSE ?
Best regards 🙂
January 11, 2019 at 9:46 am #48791If you have multiple servers I would highly recommend switching from the self-creating certificate process to a central Certificate Authority.
CG
February 21, 2019 at 2:29 pm #49216Hi !
After several exchanges with a DELL technician, here is what has been done :
At first: Using a .cer certificate and no longer use the .pfx
Export the computer certificate:
Start manage Computer certificates
Go to Personal -> Certificates -> Right Click -> All Tasks -> Export
Click next -> next.
Add a name
Choose a place to store the key
Second manipulation:
Use administrative credentials to open a command prompt.
At the command prompt, type the following command, then press ENTER:
netsh int tcp global set chimney = disabled
Third manipulation: Changing the wnos.ini
Timeserver = serverAD Timeformat = “24-hour format”
TimeZone = ‘GMT + 01:00’ ManualOverride = yes Daylight = yes Start = 030507 End = 100507
Language = Fr
SecurityPolicy = low
AddCertificate = certca.cer
AddCertificate = bacertbk.cer
VDIBroker = broker.ba.loc
ConnectionBroker = Microsoft
signOn = Yes EnableOK = Yes DisableGuest = yes
DefaultUser = user
DomainList = ba.loc
SessionConfig = RDP EnableGFX = yes EnableRdpH264 = yes
Fourth manipulation: (on our side the option was well unchecked)
First, run Server Manager/Roles/Remote Desktop Services/RD Session Host Configuration/
Next double-click RCP-Tcp
Finally, in the General page, make sure “Allow connections only from computers running Remote Desktop with Network Level Authentication” is not enabled
Fifth Manipulation: Changing the Security Layer to Negotiate (Tasks> Edit Properties> Security)
We made the requested change (RDP Security layer -> Negotiated) The problem was still present.
When I looked at the Screenshots, the encryption level was in “client compatible” and on our side in “Low”.
So we made the change to test out of curiosity and it worked!
According to DELL it should have been by default during the installation and that normally with the option in “weak” it could work (not for us in any case)
I took the opportunity to return the default wnos.ini file (without the options they had added) which had no impact, we no longer encounter the problem of double authentication for the moment.
Best regards 🙂
February 21, 2019 at 2:31 pm #49217So that’s the final screen:
-
AuthorPosts
- You must be logged in to reply to this topic.