If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.
Solved
The publisher of this remote connection cannot be verified. Type RemoteApp program.
Posted on 2011-09-08
When user try to open a RDP file to lunch program on the one of the Terminal Servers, warning message pop up:
The publisher of this remote connection cannot be verified. Do you wwant to connect?
Publisher: Unklnown publisher
Type: RemoteApp program.
It work if click Connect button. How to get rid of this message?
RDP file is aleredy signed with self signed certificate from that server.
9-8-2011-4-59-08-PM.jpg
The publisher of this remote connection cannot be verified. Do you wwant to connect?
Publisher: Unklnown publisher
Type: RemoteApp program.
It work if click Connect button. How to get rid of this message?
RDP file is aleredy signed with self signed certificate from that server.
9-8-2011-4-59-08-PM.jpg
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
2
5 Comments
The easy way is to check the box on the popup that says "Don't aks me again..." and then click connect.
The better way is to install the certificate used to sign into the trusted root store on the client computer.
The better way is to install the certificate used to sign into the trusted root store on the client computer.
We have multiple Terminal server users, so we look for centralized solution. That will apply to all users.
How to install certificate into the trusted root store? What kind of certificate? How to create one?
We have 8 Terminal Servers. Do I need to get a 8 certificated (one per server)?
I really need answer on these questions in details. Thank you.
How to install certificate into the trusted root store? What kind of certificate? How to create one?
We have 8 Terminal Servers. Do I need to get a 8 certificated (one per server)?
I really need answer on these questions in details. Thank you.
I'll try to answer all your questions but first can you give me some additional information about your environment?
You mention in your original post that the RDP file is signed with a self signed certificate.
Does each terminal server have a unique self signed cert?
Are you willing to change that?
Do you have have an internal PKI?
Do any of your users access the RemoteApp from external (public) computers?
If so, have you considered a 3rd party cert from a CA such as VeriSign?
Are all users/computer domain members?
You mention in your original post that the RDP file is signed with a self signed certificate.
Does each terminal server have a unique self signed cert?
Are you willing to change that?
Do you have have an internal PKI?
Do any of your users access the RemoteApp from external (public) computers?
If so, have you considered a 3rd party cert from a CA such as VeriSign?
Are all users/computer domain members?
You mention in your original post that the RDP file is signed with a self signed certificate.
Does each terminal server have a unique self signed cert?
Yes
Are you willing to change that?
Do you have have an internal PKI?
No
Do any of your users access the RemoteApp from external (public) computers?
No,
If so, have you considered a 3rd party cert from a CA such as VeriSign?
Yes, but like to review a option on having own CA
Are all users/computer domain members?
Yes
Does each terminal server have a unique self signed cert?
Yes
Are you willing to change that?
Do you have have an internal PKI?
No
Do any of your users access the RemoteApp from external (public) computers?
No,
If so, have you considered a 3rd party cert from a CA such as VeriSign?
Yes, but like to review a option on having own CA
Are all users/computer domain members?
Yes
If you want to have your own CA that would work very well for your scenario. You already have an environment that is well suited. By that I mean that all your users are domain joined so you can use group policy to push certs. You don’t have external users or public computers accessing the terminal servers.
Before turning up a PKI you first need to make a few decisions. For example, how large is your environment? Do you plan to buy dedicated servers or install CA’s on existing servers? Would a single stand-alone server be sufficient or would a two tier setup with an offline root CA and an online issuing CA be more reasonable, especially from a security stand point. If two tier or dedicating a box just for certificate services is not practical or cost effective then you can install a CA on any server but a hardware security module (HSM) to protect the CA’s private key might be a good investment. Your root CA’s private key is the heart of your PKI security. If compromised all certificates should be considered worthless so protect that private key at all costs.
Once you make those decisions and get a CA or CA hierarchy in place you can do the following.
Manually create a certificate for signing the RDP files. Install that one certificate on all terminal servers. Some would use unique certificates on each server but it isn’t necessary. Although you could do that as well. Once installed create new RDP files using the new certificates to sign them. Finally, modify your domain group policy to push the CA’s public key to all clients trusted root store.
I’m sure you’ll need more info than the above but this will give you a starting point.
Before turning up a PKI you first need to make a few decisions. For example, how large is your environment? Do you plan to buy dedicated servers or install CA’s on existing servers? Would a single stand-alone server be sufficient or would a two tier setup with an offline root CA and an online issuing CA be more reasonable, especially from a security stand point. If two tier or dedicating a box just for certificate services is not practical or cost effective then you can install a CA on any server but a hardware security module (HSM) to protect the CA’s private key might be a good investment. Your root CA’s private key is the heart of your PKI security. If compromised all certificates should be considered worthless so protect that private key at all costs.
Once you make those decisions and get a CA or CA hierarchy in place you can do the following.
Manually create a certificate for signing the RDP files. Install that one certificate on all terminal servers. Some would use unique certificates on each server but it isn’t necessary. Although you could do that as well. Once installed create new RDP files using the new certificates to sign them. Finally, modify your domain group policy to push the CA’s public key to all clients trusted root store.
I’m sure you’ll need more info than the above but this will give you a starting point.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
OfficeMate Freezes on login or does not load after login credentials are input.
After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
This tutorial will walk an individual through locating and launching the BEUtility application and how to execute it on the appropriate database.
Log onto the server running the Backup Exec database. In a larger environment, this would generally be …
This tutorial will show how to configure a single USB drive with a separate folder for each day of the week. This will allow each of the backups to be kept separate preventing the previous day’s backup from being overwritten.
The USB drive must be s…
Suggested Courses
Course of the Month8 days, 16 hours left to enroll
721 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.