Server manager, Internet information Services, Credential Service Bridge - service

I'm trying to create a Credential Service Bridge on a windows Machine, each time i try to Add Roles and Features through Server Manager i get this message shown below.

Related

Kerberos service authentication

I have installed Kerberos on my Cloudera manager server and I want to control which components each user can use through Kerberos. Currently, once you create a principal for the user, he immediately can use every service/component.
So is it possible to control which services (Impala, hive, etc.) a user can use through Kerberos? Or not?

How can I authenticate with the machine account during SPNego authentication?

My goal is to create a HTTPS REST service that (in concept) allows a machine account to authenticate using the less- than documented machine$ account.
I have a REST endpoint for an AD connected intranet application. Right now IIS simply echoes the thread CurrentPrincipal when I navigate using Internet Explorer.
Now I'm using the HTTPClient , using default authentication, running a my username, and that also works.
My new goal is to send the AD Connected machineAccount (that ends in the dollar sign $) so that IIS responds with the kerberos name Domain\TestServer$
I attempted creating a Windows Desktop service, running as NetworkService or LocalSystem, and I'm not clear if HttpClientHandler.UseDefaultCredentials is sufficient for running in this (unusual) context or if a different approach is needed to authenticate using the machine account.
Is a PInvoke needed? Is there anything in logonuser32 that needs to be done?

Set TrustedHosts on Visual Studio Team Services

I'm trying to deploy a build to a VM using the Manage IIS App agent task on Visual Studio Team Services. However, when I attempt to connect via HTTP, it comes back with the following error:
The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts
Unfortunately, I don't have the ability to deploy over HTTPs for reasons beyond my control so I'm trying to get around this issue by setting the VM as a trusted host, but I can't figure out how to do this using VS Online.
You can’t add trusted host to Hosted build agent (Get access is denied result if add trusted host via winrm command during build)
You can setup a new build agent and configure it to add trusted host with winrm s winrm/config/client '#{TrustedHosts="RemoteComputer"} command, after that, using this build agent to build/release.
About how to setup a new build agent, you can refer to this article.

using Windows Azure Connect local endpoint to send email from web role

I am trying to send email using one of our on-premises servers from one of my web roles hosted on azure. We've got a Windows Azure Connect endpoint installed on this on-premises server which has an SMTP server.
We've configured the web role so that it contains an activation code I acquired using the windows azure portal and the azure subscription we have. The web role has been deployed to azure with this configuration. Looking in the virtual network section of the portal I can see our on-premises server listed as well as the instance of said web role. I Created a group connecting the local endpoint to the web role instance.
The problem I'm having now is figuring out exactly what I have to do in order for the emails I send from the web role to be relayed through the smtp server on the on-premises server.
My first thought was to just specify the local endpoint name as it appears in our azure portal as the host to use when I create my SmtpClient object in code. Of course this didn't work as I received an SmtpException just saying Failure Sending Email.
So my question is once I've set everything up as described above, what do I need to do in ,my web role code and/or configuration in order to use the local endpoint as the smtp host for sending out my emails??
How about open your firewall for the SMTP on both your azure VM and local server.
As I know the azure VM firewall disabled the PING (ICMP) but doesn't know if it blocked all ports except those defined in your CSDEF file.

Test agent cannot connect to Test controller on Windows Azure

I wanted to create a Test rig on cloud. I have created a windows azure hosted service that installs Test Controller and configures it with on premise DB. I have created another hosted service that installs Test Agent. I have enabled Virtual network in the Azure service by providing Activation token taken from azure portal. I also created a Azure Connect Group in which I added my local endpoint(On Premise DB) and windows azure roles( Test Controller rand Test Agent). When I deploy this on azure I am facing problem of Test Agent connectivity with Test Controller.
Test Controller can ping to my on premise DB machine and vice versa. But my test controller machine cannot ping test agent machine or vice versa on cloud.
I have ensured following things on test Controller
User testagent is part of group TeamTestAgentService
User testagent is also administrator on TestController hosted service.
Firewall exceptions have been added
If I try to ping two azure machines I cannot do that. By default azure has ping disabled so I added following firewall rule
netsh advfirewall firewall add rule name="ICMPv6" dir=in action=allow enable=yes protocol=icmpv6
but it still does not work. I think if these two machines will be able to ping each other the problem of test agent connectivity to test controller on cloud will be solved.
Reply from http://social.msdn.microsoft.com/profile/rlfh/
It won’t work as you have it now. The controller and agents have to be in different roles, but also the controller you need to install Azure Connect as an endpoint– not enabled as a role. So, you want to configure the Controller manually, then it should show up so you can add it to the Connect From list. Leave the agents as they are(azure connect as a role) and then it should work. The Roles in the Connect TO: part won’t be allowed to intercommunicate, though an endpoint can – since they have the option you selected to allow this.
My problem was solved when I manually installed Azure Connect endpoint from azure portal on the controller machine instead of enabling it as a Role in Virtual network.