We're currently having an issue where when someone tries to access our TFS server via Visual Studio, they're hit with an Error TF30063: You are not authorized to access
The TFS server is on a different domain to what the client machines trying to connect are on. There is a domain trust between the two and other shared resources work fine.
I have found that it does temporarily work if you open up an RDP (remote) connection to the server in the background and login using your local domain credentials. After leaving your remote session connected and trying to connect again via Visual Studio, it works fine.
Another thing to point out which indeed would be related is, looking at the Administrator group permissions on the TFS server it does not resolve the usernames of the users in the list until they initiate an RDP connection atleast once after a reboot has occurred. Instead it shows their SID.
Things I’ve tried so far are;
Adding Windows and Generic Credentials to the Credential Manager on the TFS server for their domain accounts. I thought it might be an issue with the server not caching their credentials which meant an RDP connection needed to exist each time.
Enabling Windows Authentication in IIS
Adding the path to Trusted Sites in Internet Options
Enabling Network access: Allow anonymous SID/Name translation in Group Policy for the machine.
Creating a registry key under HKLM\System\CurrentControlSet\Control\Lsa called TurnOffAnonymouseBlock and set to 1 which essential is what the GP above does.
None of these however have seemed to fix the issue.
Any suggestions would be greatly appreciated!
If there is a domain trust in place, you should just add the users AD account that they log into their machine with, as a valid user in TFS.
For example, if TFS is in Domain A, and the user's laptop is in domain B (and they login to their laptop with a domain B account), then you need to ensure that Domain A trusts Domain B (either a two-way trust, or one way with A trusting B). Then you just need to make sure to add the user's domain B account as a TFS Contributor for example, and they should be able to access TFS without doing anything special.
Related
I've got 2 machines:
A corporate desktop machine which is running Windows 7 SP1 which resides on the corporate domain and which I log into using a corporate domain account.
A personal laptop that I use when working from home via the Cisco VPN client but presently sits on my desk connected to the corporate WiFi (though I had it connected to the wire and on the same subnet as my desktop machine today also). This machine is not on the corporate domain; I log into this machine with a Microsoft Account.
I need to run Visual Studio 2013 Release Management Client from both machines. The machine on my desktop works fine when entering either the IP address or the URL into the Release Management Server URL entry field and everything hooks up and all is glorious.
On my Windows 10 laptop however, it's a different story. Every attempt to connect is met with the error:
The server specified could not be reached. Please ensure the
information that is entered is valid (please contact your Release
Management administrator for assistance). <-- I'm the admin
I can ping the machine both with IP address and with hostname, ruling out DNS issues. Both client machines are on the same subnet. Both machines are using the same outbound port.
Checking the event log I see a bunch of Message: The remote server returned an error: (401) Unauthorized.
Checking with Fiddler, on my desktop machine, I can walk through the handshake of each of the stages of startup and all is good. But in Fiddler on my laptop I see 3 401 Unauthorized errors before Release Management Client bombs and returns the rather uninformative message I posted above.
I've attempted to create a shadow account on my laptop and do the Shift-Right Click-Run As Different User dance, but I must be missing something because I can't get this to run.
I've talked to the network administrator who suggests that I should be able to access all of the same resources from both machines and that it must be a Release Management issue.
Is this an incompatibility between VS2013 Release Management & Windows 10 or something else? Has anyone else had this issue and overcome it? I have access to be able to administer the Release Management environment if there's changes that need to be made there and I'm a local administrator on both machines. I'm not however a domain administrator if changes need to be made there.
I would bet you simply have a security issue as the workstation is not domain-joined and the WPF client is using Integrated Authentication.
Often creating a local "shadow" user with same username and password, and running the client app under that account (run as) works.
Another option is to join the workstation to the domain or use a domain-joined VM.
After fully investigating the situation, it appears to have been a combination of factors. I am posting a response because this appears to be a relatively common problem:
The workstation was sending an unexpected credential to the server. To get around this, you have to configure the user account on the server without a domain in the username and create a shadow account on your local machine. When running the client application, you must either log into this shadow account on the local machine or you must SHIFT+RIGHT CLICK and choose "Run as" entering your local shadow credentials. This will then pass the shadow account to the server which will now authenticate without referencing the domain. OR
Create a user account on the server that matches the credentials on your local machine including MACHINENAME\LocalUsername
There appeared to be a network issue when attempting to connect to the Release Management Server from the non-domain machine when connected inside the network. When connecting via the VPN from home, this situation was resolved, but only after we'd ensured the account and local machine accounts were correctly configured. The domain connected machine always connected properly.
I need to realize OPC server, on Windows XP. I download OPC library, and OPC client (application not library). I realize my OPC server, when i use client on my machine all runs normally. But when i connect from remote computer i do not see my server. I understand that the technology dkom potentially dangerous. I get this manual, and did everything on it, but nothing changed. I disable my windows firewall, add 135 port in windowds firewall exception. In dcomcnfg grants local and remote access to "anonymous" and "all" groups, grants local and remote launch & activation to "administrators" and "all" groups. And nothing changed, i did not give the right of my DCOM component because i thought the following: i get list of servers not work with them. In my microsoft network no domain and active directory, can i achieve the desired result in this case?
There's a number of things which can go wrong with OPC DA over DCOM. From the top of my head, you could try the following:
Check if OPCEnum service is running on the server computer. This service provides the list of OPC servers on to the potential clients. It's part of the OPC foundation redistributable.
Make sure that whatever dcomcnfg changes you applied, they are done both on the server and client computer.
If you're using only local users, try creating a dedicated user for OPC access on both server and client computer, e.g. call him "opc". Then grant all the rights to this user in "COM security" section of dcomcnfg. Run both the server and client as "opc". Make sure the local users authenticate as themselves (see "Security options" in local policies).
If all else fails, a workaround can be to deploy the server on the client computer, register it, then remove it. Worked for me once.
The most common error is DCOMs have not been configured properly. I find this guide very useful:
ftp://ftp.nist.gov/pub/mel/michalos/Software/Github/MTConnectSolutions/MtcOpcAgent/doc/DCOM_Config_Step_by_Step.pdf
Also this other guide gives you a big understanding of a Remote OPC DA:
http://www.kepware.com/Support_Center/SupportDocuments/Remote%20OPC%20DA%20-%20Quick%20Start%20Guide%20(DCOM).pdf
I had a similar problem when I tried to communicate with a remote OPC server in a different PC. Please pay attention to the point number 2 of the second guide (2.Users and Groups), make sure both PCs are logging in under the same user account with the same password.
2.1 Domains and Workgroups When working within a workgroup, each user will need to be created locally on each computer involved in the
connection. Furthermore, each user account must have the same password
in order for authentication to occur. A blank password is not valid in
most cases. Because changes may need to be made to the local security
policy on each computer, remote connectivity within a workgroup has
the potential to be the least secure connection. For more information,
refer to Local Security Policies. When working within a domain, local
users and groups are not required to be added to each computer. A
domain uses a central database that contains the user accounts and
security information. If working within a domain is preferred, a
network administrator may have to implement the changes. Mixing
domains and workgroups will require both computers to authenticate
with the lesser of the two options. This means that the domain
computer will require the same configuration as it would if it were on
a workgroup. Local user accounts must be added to the domain computer.
We have an instance of IIS6 running an intranet website with Windows Authentication and Impersonate = true so that it uses the NT credentials passed in by the clients browser.
The AppPool is set to run as a network service user: serviceAcctX so that we can undo impersonation in rare cases (to read or write a resource that the client user does not have access to)
It works perfectly when the source of the virtual directory is on a local drive. The logged in user is authenticated and page content is customized based on authorization settings.
Our infrastructure team is trying to move the virtual directory source to a file share on a remote server. We have already gotten past the issue with changing the .Net security policy by adding a full trust for that specific file share path. We have set the Connect As property to the same serviceAcctX, the same one that the AppPool is running as.
The site starts fine. However, the client user is not impersonated. The request is processed using the default serviceAcctX credentials instead of with the client's NT credentials as before.
Is there a way to have the client impersonation still work as before and still have the virtual directory on a file share? Any pointers are greatly appreciated.
I'd put this in the category of Not A Good Idea.
There are a number of potential problems that crop up and you are introducing a lot of dependent complexity.
Instead, I'd go for something a little more "offline" than this. Use File Replication to keep the files in sync between your web server(s) and remote server.
Although slightly complex, it increases the survivability of your application. Meaning, if the remote server reboots, goes down, or there is a network problem between the two, your app is still functional. Further, you are still able to have the files on the remote server.
You may have to check the "trust this computer for delegation" check box in Active Directory for the web server in order for the user's token to be passed on.
IIS5 is running on SERVER1.
One of the virtual directories in IIS, myfiles, is pointing to "A shared location on another computer", //SERVER2/myfilesshare
When I try to access the page:
http://SERVER1/myfiles
... I get the error:
You are not authorized to view this page
HTTP 401.1 - Unauthorized: Logon Failed
Internet Information Services
I have triple-checked the "Connect As..." settings in IIS. The credentials I'm using to access the share are correct-- they work when connect to the share in Windows Explorer, but not through the IIS virtual directory.
I've tried granting full permission to Everyone on the folder in SERVER2, but no luck.
Any thoughts?
This was how I solved my problem, might help you.
By default, IIS uses local user called IUSR for virtual directories when using anonymous authentication. It does not use application identity, which should be obvious, if you use procmon.
How can you force it to use application identity?
Easy, under IIS manager:
1) go to Authentication
2) Edit "Anonymous authentication"
3) Select "Application pool identity"
4) Restart IIS & it should work.
The same accomplished with PS: Set-WebConfigurationProperty -filter /system.WebServer/security/authentication/AnonymousAuthentication -name username -value ""
This link contains the pros/cons: http://blogs.technet.com/b/tristank/archive/2011/12/22/iusr-vs-application-pool-identity-why-use-either.aspx
Permission issues can be tricky. Try running filemon on the 'other computer' It can be downloaded over here: http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
(it's not a big application just a tiny lightweight tool)
After you've started filemon, stop the monitor process (I believe it's turned on by default when you start the application), clear the logged data, create a filter for the folder you have trouble getting access to. Start the monitor process. Request your webpage. Stop the monitor process and look for "access denied" messages in filemon. When found, filemon will also mention the name of the actual user which is trying to get access. This might help you to get to a solution.
Btw when using Windows Server 2008 you will need processmon instead: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Imagine a scenario where for whatever reason you want to have your IIS Server access a Share on a File server and they are not on the same domain.
If you can follow and get this to work for you (I have done it Win2008-R1 32-bit File Server and Win2008-R2 64-bit with IIS 7), then you should be in good shape for any scenario.
Same name local account on both servers with same password
On IIS, use aspnet_regiis -ga MyAccount to give local account access to IIS guts
Now use that as the Application Pool Identity of the Website
Using Local Security Policy (Admin Tools) enable trust for delegation for local account
Restart IIS server
On File Server, use Local Security Policy to enable access from network for local account
Create Share granting desired permissions to local account (also Security tab permissions as needed)
Open up File & Print Sharing ports on both (as restrictive as possible) to point where it works for you when you are using Windows Explorer between the two
Back to IIS, create Virtual Directory using UNC path to Shared folder from File Server
Just use Pass-through authentication (which would use your local account)
You can tell Anonymous Authentication setting of the Virtual Directory to use Application Pool Identity as well
Use something that will test/verify. The key really is trust for delegation using a Service Account (domain or otherwise), and having IIS use the account you want it to use instead of Local Server or Network Service.
This took me all day to figure out. Various threads in StackOverflow and other Internet sources helped point me to various resources me but didn't find my exact answer anywhere. Hopefully next person stuck with this problem will get a speed boost on the path to resolving with my description of what worked for me.
try enabling windows authentication on the virtual directory security tab (in IIS).
I have recently had some problems that I think might be helped by debugging my ASP.NET MVC application in IIS instead of with the default ASP.NET Development Server. However, when I try this the application can't access the database server (MS SQL Server 2008 Express) - it works fine on the Development Server though.
The error I get is
Cannot open database 'myDbName' requested by the login. The login failed.
Login failed for user 'NT INSTANCE/NETWORK SERVICE'.
I assume it worked before because the development server accessed the database through my user account, and not via the network service like IIS.
I tried adding the user NETWORK SERVICE to the database, but it turns out I don't have the user privileges to do so - it doesn't matter that my Windows account that I log on to the server with is admin, or that I run the program in an administrator context. I just can't add another user to the DB.
How do I solve this problem?
You could change the user that IIS runs under: it's a setting in the properties for the ApplicationPool that your web site's running under.
We do this all the time as it gives us better control over user access - that NT INSTANCE/NETWORK SERVICE account's a bit too magic for my liking...
NETWORK SERVICE is a special account. If your database server is on another machine from your IIS server, you need to add the account:
\$ as a user for the database. So if you're on a IIS Server called LISA on the SPRINGFIELD network, you would need to grant access to SPRINGFIELD\LISA$ to your database. Note the dollar sign which denotes your user as a machine account and not an actual person.
If your database server and your IIS server are one and the same, grant access to the account "NT AUTHORITY\NETWORK SERVICE". That's the whole name of the account. And that should work.
Are you running a non-english Operation System?
For some reasons, the account name of "NT Authority\Network Service" has been localized in other languages.
Sadly, a lot of programs have the account name hard coded to the english name, and won't find the Network Service when running on foreign versions of Windows.