I´ve setup a Test Controller and several Test Agents on VMs. I was able to connect to the Test Controller with every Test Agent except the one installed on a Windows 7 Starter edition. Problem is obvious. Win 7 Starter can not join the domain where the PC hosting the Test Controller is located. How can i get around this problem? Thanks for your help!
What have you tried so far? There's a number of resources that talk about cross domain issues.
Try 2.2. Controller/Agent in untrusted Windows domains or one is in a workgroup and another one is in domain.
From: http://social.msdn.microsoft.com/Forums/en-AU/vststest/thread/df043823-ffcf-46a4-9e47-1c4b8854ca13
Mirror user account on Controller and Agent: create a user account with same user name and password on both Controller and Agent machine.
Use mirrored user account to run Controller and Agent services under this account.
If you are using VS2010 RC+ version (i.e. RC or RTM but not Beta2), add the following line to the qtcontroller.exe.config file under the appSettings node:
<add key="AgentImpersonationEnabled" value="no"/>
Restart Controller/Agent services (see Tools section in the Appendix).
Make sure there is no IP Security Policy that prevents the connection (see IP Security Policy under Tools section in the Appendix).
By default for domain machines Windows uses domain (Kerberos) authentication, but if it fails it will fall back to workgroup (NTLM) authentication. This behavior can be and often is altered by IP Security policies, for instance, there could be a policy to block connections from machines which do not belong to the domain.
Restart or re-configure Controller and Agent.
Or Running Tests cross domain with TFS and Visual Studio 2010
http://blogs.msdn.com/b/dustin_andrews/archive/2010/08/12/running-tests-cross-domain-with-tfs-and-visual-studio-2010.aspx
There is one problem with Mirroring Accounts for both Test Controller and Test Agent, it will not work if you register your controller to TFS team collection.
Why? Cause if you run your Test Controller and Test Agent under workgroup account,TFS server will disconnect the Test Controller cause authentication issue. If you ran Test Controller under domain account and Agent under workgroup then Test Agent will not be authenticated by Test controller.
Unless I am missing something it will not work if you need your Test Controller to be register to TFS team collection.
Related
Noob Question:
I have a Jenkins instance setup on an internal team domain (with our own DNS/AD configured). This domain is inside the intranet.
We have security enforced on Jenkins using the Active Directory plugin. Therefore, all users login with their AD credentials for an actions like triggering a job, etc. Viewing is open to all.
We access the Jenkins instance using the DNS name (http://jenkins.team.company.com:8080). However, when accessing certain jobs, the address changes to http://10.XX.XX.XX:8080/../..). At this point, the users' logged in sessions are also terminated.
I am at a loss about what is causing the sessions to get lost.
(in the spirit of full disclosure - this Jenkins instance does not have an nginx or apache running in front of it. Until recently, this was my own local Jenkins instance but now the ask is to get everyone to start using this. I am wondering whether setting up nginx or Apache will resolve the problem. You can tell that I have none or very little background with running Web Applications)
I have an MVC 3 application and WCF service to be deployed in IIS 8.5 installed on Windows Server. I have checked all the prerequisites installed for IIS 8.5. After the deployment when I try to access the .svc files, I get "This page can't be displayed".
The have verified the below conditions.
APP POOL:
1.) The app pool is set to "Integrated" mode and targetted to V4.0.
2.) Identity is set to "ApplicationPoolIdentity" and enabled 32 bit
applications.
BINDINGS:
1.) Provided a different port"88" and ip address is configured.
PERMISSIONS:
1.) Full access has been provided for the below mentioned users.
a.) IUSR
b.) IIS_IUSRS
c.) DefaultAppPool(This is the app pool that has
been assigned).
I am struck with this, Please let me know for anything that needs to be included.
Do you have HTTP Activation checked for WCF Service under IIS features. If not you need to enable that from server manager add roles/features wizard. Please refer to the image attached.
I would like to be able to run/debug locally. The machine is a laptop that is on a domain, however at times I do take it home. I have IIS installed as well as SQL Server. Everything is running correctly. I just have one issue, I must be on the domain so that the MVC site that configured to use Windows Authentication will run. I would like to figure out how I can remove this dependency on the domain controller. Specifically I would use local users when I am not connected to the domain, or only use local users in development testing.
Add this to your web.config file for your website:
<add key="AuthorizedADGroup" value="Administrators"/>
Anyone in your local Administrators group will then be able to access the site through Windows Authentication. Alternatively, you can also create a local group called say "Developers" or "Testers" or "Engineering", add local users to those groups, and sub one of those groups in for Administrators instead.
using IIS 6
I have the default web site that works and can authenticate users to the domain when they connect.
I have created a second website, siteb, put a host (a) record into DNS, I can browse to it as long as I have use anonymous access, when I select windows authentication, it fails...
not sure what i'm missing here...
Thanks.
This goes beyond just IIS if you're using Integrated Windows Authentication. You've created "siteb" in DNS which allows your users to connect to it so this is good. However, when their browser requests a Kerberos ticket for "siteb" from Active Directory, AD is probably responding that it cannot find "siteb". You can verify this with Wireshark.
The fix is to add "siteb" (and any other permutations with which you expect users to access the site) as an additional servicePrincipalName for the server's machine account in AD. You can accomplish this with the "setspn.exe" utility. It should be available on your domain controller. If not, you can install it from the Windows 2003 Support Tools.
Some examples of adding a UPN alias with setspn on the DC are:
setspn.exe –A HTTP/siteb <server hostname>
setspn.exe –A HTTP/siteb.acme.com <server hostname>
This should take effect immediately. The final step is ensuring that the browser "trusts" the new website name. In Internet Explorer, for IWA to occur automatically, the server name should be listed in either the Trusted Sites or Intranet zone.
Of course, you could avoid all this hoopla by having the 2nd website just run on a different port under the same name, e.g.: http://sitea:81
Have an app on server ion. It calls a webservice on server2. Endpoint of that service is to write a pdf file on server3.
As a developer in dev on my laptop it works. As a deployed app it fails on the write.
IIS6, Windows 2003 servers as well as VS2008
AppPool Identity as network service will not write the file. If I use a "fake" user in AD the app pulls no data and fails to start up properly.
Any ideas?
TIA
My guess is that the credentials that are running the app on server2 does not have write permissions to server3 (assuming server2 uses a UNC path to write to the filesystem on server3).
The user account that runs the IIS Application Pool (or however credentials are assigned to your app(s)) on Server2 will need write access to the share/UNCpath on server3; generally this means you cant use NetworkService.
If you change the user account in IIS on server2, you'll need to take into account all the implied permissions that the existing user account (assuming NetworkService) has on server2.
Including Filesystem, Registry, Metabase, etc permissions; the list could be very long and complicated or short and irrelevant (depending on your implementation on servers1/server2/server3).
For all my implementations, we use AD User accounts that are designated as Service Accounts; with extremely limited permissions on the servers, each App would have its own Service Account, and any touch-points would require explicit permissions applied. Thus, an account would be setup for the app on Server2 and the explicit permissions would be configured on Server2 to run the app, and the UNC path/share and NTFS permissions on Server3 would be applied explicitly for the file transfer.
Hope this helps.