We have two domains on our network : domain A and domain B with a trust between them. We created AuereDevops 2019 update 1.1 server as on premise in domain A and want users from Domain B to access and use this AzureDevops. Since this AzureDevops server was set to work via port 80 (not 8080), we opened access in Domain A to port 80, and also port 443 of this server (although we defined to use http not https).
Following, we can connect via web access from Domain B to the server in Domain A, but cannot do so from team explorer in visual studio, from a computer in domain A. The team explorer within Visual Studio shows only the name of the server in domain B but no siblings within it (i.e. no team projects to connect).
Another cross domain issue occurs when assigning Work Item to a user in domain A - no email is received to notify about it. Only when explicitly sending mail from the work item windows, the email is received.
Can u pls advise how to overcome this problem ? Thank u
We found where the root of the problem is and fixed it as follows.
The reason why couldn't connect from visual studio in domain A to AzureDevOps server in domain B, was because visual studio does not support suffix ".domainB" for the tfs server. We defined a DNS mapping for the server in domain A, and this resolved the issue. Now connection from VSTS is done by directly providing the server name of Domain B.
Related
No matter what I do Visual Studio 2017 maintains an HTTP connection to TFS. Our TFS server was recently moved to an SSL/HTTPS connection. If I disconnect my connection and reconnect to:
https://tfs.myorg.com:443/tfs
The connection becomes:
http://tfs.myorg.com:8080/tfs
NO MATTER WHAT I DO, NOTHING CHANGES THIS URL. I even tried using the IP address of the server. It still shows up as 8080.
Further Information:
I discovered that both URL's are still active until every developer is migrated over to SSL. I apparently cannot migrate until the HTTP connection is removed maybe?
You could change the setting in IIS, select the TFS under Sites, then Application Settings, setting name sslOnly . If the value is false changed to ture.
Now your team can only access the TFS portal from inside and outside using https only. This means that VS can also connect to TFS via https only.
More details please take a look at this link which describing the redirect behavior from the URL.
If above still not work, try to clear TFS and VS cache and test again.
I have hosted asp.net core app in IIS on window server 2012 R2 Standard. My site works fine when I use localhost based URL on the machine but when I try to access the URL using host name/machine name from network computer it does not work. What do I need to do to make it accessible from other computers?
There can be different reason for this:
Check your firewall to make sure your port 80 is open.
Check that the hostname point to the IP URL of your server.
What is the http code returned by the it does not work?
Tool:
Enter the Domain and IP, make sure they point to the same place.
http://www.hcidata.info/host2ip.htm
If firewall isn't the problem, and the site works via localhost on the server, make sure your IIS bindings are correct. Right click site, edit bindings, verify the domain / ip / etc match how you're trying to access it.
I am using a virtual server hosted anywhere (the virtual machine has Windows Server 2012 Datacenter R2 installed), but is not an domain controller. Now I installed Team Foundation Server 2015 RC (it's the release candidate but I think I will get similar problems with other versions) and the URL's are populated using the machine Name.
For example if my domain is abc.de, and my hostname is vmd12345, then the populated urls are something like this:
http://vmd12345:8080/tfs
Accessing repositories from visual studio is not a problem, but when I do some actions (for example view build logs), the web application tries to request vmd12345, what in fact is not accessible outside of the server. I tried to change the urls using the change url button in the TFS admin console, but if I do the system ask for a username and password and I do not know which user account is required.
Trying to change the URL's using the admin console failed cause the system has asked by to enter the credentials (I guess the credentials of the configured service user is ment), but the credentials did not work.
Further investigations shows that this is caused by an IIS problem of the webpage the TFS deploys into the IIS. If I connect at localhost, the credentials of the user were accepted, using the domain name the credentials was not accepted. Any Idea of what the problem can be?
You need to open the administration console on the TFS server and on the "Application Tier" node click "change URL". At the public up only...
We're going to upgrade our TFS 2012 to TFS 2013 in the coming month - which also means we're going to update our SQL Server 2008 R2 cluster to 2012.
Furthermore - our TFS is currently hosted in a different domain from our company default domain and we want to change that to our company default domain so it can just run under our 'normal' domain controller.
So that gives us 2 possible paths for the upgrade:
In place upgrade - then migrate to the new domain
Set up a whole new environment in the new domain, and then move the old TFS to the new. This seems to be kind-of a backup-restore
operation.
My question is: what's the recommended way - what would cause the least pain?
I suggest you to access your Windows Server and launch Server Manager dashboard and select your Role and Features.
On your domain controller you have possibility to attach specific domain to your target domain.
I've just built a basic ASP MVC web site for deployment on our intranet. It expects users to be on the same domain as the IIS box and if you're not an authenticated Windows User, you should not get access.
I've just deployed this to IIS6 running on Server 2003 R2 SP2. The web app is configured with it's own pool with it's own pool user account. The IIS Directory Security options for the web app are set to "Windows Integrated Security" only and the web.config file has:
<authentication mode="Windows" />
From a Remote Desktop session on the IIS6 server itself, an IE7 browser window can successfully authenticate and navigate the web app if accessed via http://localhost/myapp.
However, also from the server, if accessed via the server's name (ie http://myserver/myapp) then IE7 presents a credentials dialog which after three attempts entering the correct credentials eventually returns "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials".
The same problem occurs when a workstation browses to the web app url (naturally using the server's name and not "localhost").
The IIS6 server is a member of the only domain we have and has no firewall enabled.
Is there something I have failed to configure correctly for this to work?
Thanks,
I have tried the suggestions from Matt Ryan, Graphain, and Mike Dimmick to date without success. I have just built a virtual machine test lab with a Server 2003 DC and a separate server 2003 IIS6 server and I am able to replicate the problem.
I am seeing an entry in the IIS6 server's System Event Log the first time I try to access the site via the non-localhost url (ie http://iis/myapp). FQDN urls fail too.
Source: Kerberos, Event ID: 4
The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/iis.test.local. The target name used was HTTP/iis.test.local. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (TEST.LOCAL), and the client realm.
After extensive Googling I managed to find a solution on the following MSDN article:
How To: Create a Service Account for an ASP.NET 2.0 Application
Specifically the Additional Considerations section which describes "Creating Service Principal Names (SPNs) for Domain Accounts" using the setspn tool from the Windows Support Tools:
setspn -A HTTP/myserver MYDOMAIN\MyPoolUser
setspn -A HTTP/myserver.fqdn.com MYDOMAIN\MyPoolUser
This solved my problem on both my virtual test lab and my original problem server.
There is also an important note in the article that using Windows Authentication with custom pool users constrains the associated DNS name to be used by that pool only. That is, another pool with another identity would need to be associated with a different DNS name.
Sounds like the new Loopback check security feature of Windows Server 2003 SP1. As I understand it, is designed to prevent a particular type of interception attack.
From http://support.microsoft.com/kb/896861
SYMPTOMS
When you use the fully qualified domain name (FQDN) or a custom host header to browse a local Web site that is hosted on a computer that is running Microsoft Internet Information Services (IIS) 5.1 or IIS 6, you may receive an error message that resembles the following:
HTTP 401.1 - Unauthorized: Logon Failed
This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address.
Note You only receive this error message if you try to browse the Web site directly on the server. If you browse the Web site from a client computer, the Web site works as expected.
CAUSE
This issue occurs if you install Microsoft Windows XP Service Pack 2 (SP2) or Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 and Windows Server 2003 SP1 include a loopback check security feature that is designed to help prevent reflection attacks on your computer. Therefore, authentication fails if the FQDN or the custom host header that you use does not match the local computer name.
Workaround
Method 1: Disable the loopback check
Method 2: Specify host names
See http://support.microsoft.com/kb/896861 for details.
Edit - just noticed that you said you were seeing this from Client PCs as well... that's more unusual. But I'd still look to test one of these workarounds, to see if it corrected the problem (and if so, might indicate a problem with your DNS config).
It sounds to me as though you've done everything right.
I'm sure you are but have you made sure you are using 'DOMAIN\user' as the user account and not just 'user'?
IE7 only sends Windows credentials (NTLM, Kerberos) if it identifies the server as being on the Intranet. IE7 also added an Intranet zone lockdown feature - if you're not on a domain, by default no servers are in the Intranet zone. This was done to prevent zone-migration attacks.
To change this, go to Tools/Internet Options, Security tab, then click Local Intranet. You can then manually add servers that should be treated as Intranet, by clicking the Sites button, then Advanced, or tell IE not to automatically detect your Intranet and selecting the other checkboxes as appropriate.
I just encountered the opposite problem - my site authenticates externally but not locally.
I compared it to the sites we have working and the difference was that the site that failed to authenticate was using Windows Authentication.
However, other sites I work with (this is a dev server) tend to have Basic Authentication.
Not sure why exactly but this fixed it.
However, at the same time I noticed "Default Domain" and "Realm" settings.
I know it's very unlikely but could these perhaps help at all?