I have a piece of legacy c# code (console application) that runs as a nightly batch and fires off TF.exe and TFSSecurity.exe commands at AzureDevOps.
The commands are built by the c# code and then executed by means of launching PowerShell and executing them.
All have worked fine until now, but lately, it started failing for tf30063 authentication errors.
TF30063: You are not authorized to access https://dev.azure.com/
As part of my troubleshooting I have picked a few of these commands that are being built and executed them in an interactive PowerShell session.
tf permission /recursive $/<tfs_project_name>/ /collection:https://dev.azure.com/<organization_name>/
TFSSecurity /imx adm: /collection:https://dev.azure.com/<organization_name>/
It produces the same result - TF30063: You are not authorized to access https://dev.azure.com/.
The logged-on user (where the commands are run) is able to access this AzureDevOps URL via a browser.
Digging a bit deeper I ran the command: tf settings connections help which returned the following output:
Server Url : https://<organization_name>.visualstudio.com/
User :
I was actually expecting the passed URL here: https://dev.azure.com/
Not sure how this URL got there, or how to get it out - but, be that as it may, the empty user field arouses some suspicion.
I am really trying to figure out what the authentication flow/procedure is when executing these commands (TF and TFSSecurity) in Powershell.
I have been prompted for authentication by an AzureDevOps dialog once, but where do these provided credentials stored? And for how long?
I have been snooping around the Windows credentials in the Credential Manager, here I found some bits and pieces - but nothing conclusive.
Question:
Does anybody perhaps know how these 2 applications (tf.exe and TfSecurity.exe) handles authentication and storing of credentials?
System specs:
OS: Windows Server 2016
Powershell Version: 5.1.14393.3053
Location (version) of the tf.exe and TfSecurity.exe
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\
Team Explorer>
The cached credentials that tf.exe referenced might get corrupted. We donot know what caused this issue, nor can we give a certain method to fix this. You have to try below possible solutions to narrow down the fix.
1,
Using the browser from within your Visual Studio, View->Other Windows->Web Browser and navigate to the https://dev.azure.com/. Then check if it is logged in the wrong account, log out and relog in if wrong account is logged in.
2,
Running the following command from the Developer Command Prompt for VS:
tf workspaces /collection:https://dev.azure.com/<organization_name>
3,
Go to Team Explorer > Manage Connections (Little Plug next to Home button) > Right Clicked on Project > Connect. Then reenter in your credentials.
4, To clear all the caches
Close all Visual Studio instances, delete %LOCALAPPDATA%.IdentityService as you did.
Clear TFS caches %LOCALAPPDATA%\Microsoft\Team Foundation\7.0\Cache
Clear all the browser caches especially for the stored password
5, Run Visual Studio as another user:
cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE
runas /netonly /user: devenv.exe
Enter the user possword, then Team Explorer > Manage Connections
If none of the obove method fixes this issue. Please check here and here for more possible solutions.
You can also report a problem to Micrsoft Develop community(Report a problem > Azure Devops) if above issue persist.
For Server Url : https://.visualstudio.com/. It is the old version dev.azure.com domain name. The official document says it can be used as usual.
Update:
TF30063 error for TFSSecurity
The cached credentials for TFSSecurity is stored in the registry. You can delete it.
HKEY_CURRENT_USER\Software\Microsoft\VSCommon\14.0\ClientServices\TokenStorage\VisualStudio\VssApp
After you deleted the cached credentials in above registry. It will prompt you to re-enter the credential when you run tfssecurity.exe command again.
I have this exact (best as I can see) scenario on a test server and it works as expected.
IIS Application needs to move a file on the D drive from one sub folder to another subfolder
D:\supportfiles\new (file is here)
D:\supportfiles\backup (file needs to be moved here)
I gave the app pool modify access to the top level folder, D:\supportfiles
This works as expected on my test server, but not on a different server that I published to. The app pool has permissions, or at least it appears it does.
I get this error
System.UnauthorizedAccessException: Access to the path is denied.
File.Move(OldPath + FileName, NewPath + FileName);
Go to advance settings of your application apppool and set it to LocalSystem instead of apppool identity. Or setup a new user specially for using in apppool.
It's usually caused for some os hardening issues on product servers.
it happened to me. console application for sure. start as an administrator and try again?
var filename = Environment.ExpandEnvironmentVariables(#"%LOCALAPPDATA%\Dropbox\info.json");
When I run it in vs I get the path I need which is
C:\Users\User-pc\AppData\Local\Dropbox\info.json
when published to IIS I get
C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\Dropbox\info.json
This is because IIS is not running under your user account. It is running under a system account. C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\ is the correct path for the IIS account.
You could set the user account on the IIS app pool to be your user (not great for secuirty, https://technet.microsoft.com/en-us/library/cc771170(v=ws.10).aspx), or you could pass the correct path in another way (web.config maybe)?
%LOCALAPPDATA% is a user specific folder.
IIS doesn't use the same user as you when you run from VS.
In my opinion there are 2 solutions :
- Change the folder of this file to something more usual (Your web site folder, or something like D:\Dropbox\info.json)
- Change the user IIS uses, but that's really not a good option
I receive an "Access Deined" COMException when I try to connect to a remote IIS 6 server from my C# application that is running under IIS 5.1.
Any ideas? I am experiencing all the same issues with the original questions.
Update - 4/1/09
I found this solution (http://www.codeproject.com/KB/cs/Start_Stop_IIS_Website.aspx) that consists of a window application connecting to an IIS server to start and stop web sites. I am able to run it on my workstation and connect to the IIS server.
Ugh....why can I run this stand alone application but not my ASP.NET application?
Original
I receive an "Access Denied" COMException when I try to connect to IIS from a remote machine using the DirectoryEntry.Exist method to check to see if the IIS server is valid.
string path = string.Format("IIS://{0}/W3SVC", server);
if(DirectoryEntry.Exist(path))
{
//do something is valid....
}
I am a member of an active directory group that has been added to the Administrators groups to the IIS server I am trying to connect to.
Has anyone experience this issue and know how to resolve it?
UPDATE:
#Kev - It is an ASP.NET application. Also, I can connect without an username and password to the remote server through IIS6 Manager.
#Chris - I am trying to connect to the remote server to display the number of virtual directorys and determine the .NET framework version of each directory. See this SO question.
#dautzenb - My ASP.NET application is running under IIS 5.1 trying to connect to an IIS 6 server. I can see fault audits in the security log for my local ASPNET account on the remote server. When I try to debug the application, I am running under my domain account and still get the Access is denied.
UPDATE 2:
#Kev - I was able to establish to create a DirectoryEntry object using the following overload:
public DirectoryEntry
(
string path,
string username,
string password
)
But, all of the properties contain a " threw an exception of type 'System.Runtime.InteropServices.COMException'" while I debug the app.
Also, the AuthenticationType property is set to Secure.
UPDATE 3:
The following two failure audit entries were in the remote IIS server's security event log every time I tried to establish a connection:
First event:
Event Category: Account Logon
Event ID: 680
Log attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon account: ASPNET
Source Workstation:
Error Code: 0xC0000234
Second event:
Event Category: Logon/Logoff
Event ID: 529
Logon Failure:
Reason: Unknown user name or bad password
User Name: ASPNET
Domain: (MyDomain)
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Workstation Name: (MyWorkstationId)
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 10.12.13.35
Source Port: 1708
Impersonation is set to true and the username and password are blank. It is using the ASPNET account on the remote IIS server.
If it is an identity problem, you could try setting your IIS 5.1 application to use Integrated Windows Authentication, and then add the following to you web.config on your IIS5.1 web site under system.web to enable impersonation.
<identity impersonate="true"/>
<authentication mode="Windows" />
Since this is an ASP.NET application, it runs in an Application Pool of IIS. This Application Pool runs using a specific user("Local System", "Network Service" or another user).
Does this user have enough rights to connect to a remote server ?
See MSDN for more info.
This looks like it may be a double-hop issue. If you are impersonating the current user of a website using NTLM, that impersonation is only valid on that server (your IIS 5.1 server in this case). If you try to connect to another server using the web site, you are actually going to have issues as it cannot pass the token to another server that was used during impersonation. The same is true if you are debugging your site through your machine, going to another box. Your local machine is authenticating you, but it cannot impersonate you to another server.
All of the solutions I have used in the past require you to hard code the app pool to use an account that has permissions, set the annony. account to a domain account with permissions on the other machine, or use a windows service running on the IIS 5.1 machine, under a domain account, to connect to the other server.
If you are using Kerberos, this wouldn't apply, but AD uses NTLM by default.
Where exactly are you trying to read too? Is it in under the same path as your application?
When I had this problem, I found that simply authenticating my self on a Windows file share solved the problem. From experience, I think that WMI/ADSI/COM doesn't have great support for not-already-authenticated users. I believe this issue occurs when you're not associated with a Windows domain.
If it is indeed a NTLM doublehop issue you could use the SETSPN utility to create service principal named instances for your target IIS servers.
Then you could go into Active Directory, and then allow the computer object (basically the NETWORK SERVICE or LOCAL SERVICE principals) to delegate its credentials to a correctly registered SPN.
Then you could hop-hop-hop all over the place! But, be warned! People can hurt themselves on sharp pointy things when you enable double-hop!
Good KB articles to read:
http://support.microsoft.com/kb/929650
I believe that DirectoryEntry.Exists silently ignores any credentials supplied and uses the creds of the authenticated user. This seems to match the behaviour you've described. For AD work, we never use it for this reason.
I'm sort of stumped at the moment as to why you can't get this working. There is a temporary work around you could try. When instantiating the DirectoryEntry object you could use one of the following constructor overloads:
public DirectoryEntry(
string path,
string username,
string password
)
Documented at: MSDN: DirectoryEntry Constructor (String, String, String)
...or...
public DirectoryEntry(
string path,
string username,
string password,
AuthenticationTypes authenticationType
)
Documented at: MSDN: DirectoryEntry Constructor (String, String, String, AuthenticationTypes)
As it happens I'm building a test AD environment on my virtual server box for a new project to do similar stuff. When I get it up and running I'll have a play around to see if I can reproduce the problem you're encountering. In the meantime let us know what happens if you try these constructor overloads referenced above.
Update (In answer to Michaels comment):
For reasons that evade me just now, we couldn't use DirectoryEntry.Exists() in a particular scenario, there is this snippet of code that gets called now and again in one of our apps:
public static bool MetabasePathExists(string metabasePath)
{
try
{
using(DirectoryEntry site = new DirectoryEntry(metabasePath))
{
if(site.Name != String.Empty)
{
return true;
}
return false;
}
}
catch(COMException ex)
{
if(ex.Message.StartsWith("The system cannot find the path specified"))
{
return false;
}
LogError(ex, String.Format("metabasePath={0}", metabasePath));
throw;
}
catch(Exception ex)
{
LogError(ex, String.Format("metabasePath={0}", metabasePath));
throw;
}
}
You could replace the constructor with one of the ones from above. Admittedly it's a stab in the dark :).
My C# application crashes under some circumstances when run with a non-admin user.
I'm experiencing a problem with Windows Server 2003 and I'm trying to find more information about it. It may be a problem on other Windows OS's.
It seems that if I create a non-admin user, and then run my application under this user with the 'Run as...' command, the users environment doesn't get set up correctly, and the TEMP environment variable points at C:\Windows\Temp instead of the users having their own Temp folder in the Documents and Settings profile. The user doesn't have permissions to this folder, so the application crashes with the .Net JIT compiler tries to write/read to this folder.
If I log on as this user, the situation is still wrong. I don't get the Environment being prepared thingy you normally get when logging on a new user, and my app still won't run without crashing during startup. Infact I've realized the user can't run calc.exe or other programs in the Windows folder. It appears that their environment is permanently messed up and I guess the only way forward is to delete their profile.
If I create a non-admin user, and log on as them before doing a 'Run as..', they're environment gets set up ok, and my application works.
I can't find any information on this problem or notes on whether Microsoft acknowledge it. Have you experienced this, or do you know where I can look to find more about it?
Consider using runas with a profile for the user if you are not.
C:\temp>runas RUNAS USAGE:
RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
/user: program
RUNAS [ [/noprofile | /profile] [/env] [/netonly] ]
/smartcard [/user:] program
/noprofile specifies that
the user's profile should not be
loaded.
This causes the application to load more quickly, but
can cause some applications to malfunction.
/profile specifies that the
user's profile should be loaded.
This is the default. /env to use
current environment instead of user's.
/netonly use if the
credentials specified are for remote
access only. /savecred to use credentials
previously saved by the user.
This option is not available on Windows XP Home
Edition
and will be ignored. /smartcard use if
the credentials are to be supplied
from a
smartcard. /user should be
in form USER#DOMAIN or DOMAIN\USER
program command line for EXE.
See below for examples
Examples:
runas /noprofile /user:mymachine\administrator cmd
runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
runas /env /user:user#domain.microsoft.com "notepad \"my file.txt\""
NOTE: Enter user's password only when
prompted. NOTE: USER#DOMAIN is not
compatible with /netonly. NOTE:
/profile is not compatible with
/netonly.