I know this question has been asked many times on SO, but none of them answer my question.
I know from studying for the Comptiat A+ that when using automated (unattended) installations techs always have to go back and change the MACHINE SID before the OS can be activated on each machine. There seems to be a lot of questions about how to get the SID with networks and such, but I know there is also a machine SID that cant be changed. For those of you who have used Fix-It Utilities boot disk, there is a button, "change SID" and that will make windows fail to boot if its already activated.
My question is similar to this one, but his question was never really answered. My question is, how do I get the MACHINE Windows Installation SID using c#.
Well, it depends which computer SID you want (seriously!). There's the SID that the local computer uses for itself... For this, you just need to get the SID of the local Administrator user, and remove the "-500" from the end to get the computer's SID.
In C# on .NET 3.5:
using System;
using System.Security.Principal;
using System.DirectoryServices;
using System.Linq;
public static SecurityIdentifier GetComputerSid()
{
return new SecurityIdentifier((byte[])new DirectoryEntry(string.Format("WinNT://{0},Computer", Environment.MachineName)).Children.Cast<DirectoryEntry>().First().InvokeGet("objectSID"), 0).AccountDomainSid;
}
On the other hand, there's the SID that Active Directory uses to identify each domain member computer... That one you fetch by getting the SID of the machine account in the domain--the one that ends with a dollar sign.
Related
Our company uses Cisco telephony. And we have a little program on user-s PC wrote by our partner. This program tracks incoming calls and for the call rises record in our CRM-System. This program uses tapi3 (it is COM-object from deep inside of windows). Unfortunately, it doesn't work on PC with Windows 10.
Search a lot for causes of this problem didn't give me even some a bit useful answers. And indeed, I am coming to the opinion, that this library by itself have some problems with working with it on Windows 10.
Well I tried a lot of things, before wrote this question. Tried to use other versions (later versions) of tapi driver for cisco (CiscoTSP). Tried to use other instances of tapi3. Tried to make this program work on other machines with win10. And now I have no result.
This small example demos the problem.
using System;
using System.Collections.Generic;
using TAPI3Lib;
namespace TestTAPI
{
class Program
{
static void Main(string[] args)
{
var tapi = new TAPIClass();
tapi.Initialize();
List<String> names = new List<string>();
foreach (dynamic address in (tapi.Addresses as ITCollection))
{
names.Add(address.AddressName);
}
}
}
}
In result of execution I have empty List of Addresses, but it shouldn't be empty.
At least I should be see standard tapi Addresses, but I didn't. Moreover I see in "Control Panel" -> "Telephone and modem", that I have more Addresses then only standards.
Really don't know what is going wrong. Maybe I miss some details?
Or may be I can change using tapi3 to something else to make that work.
Assuming it works on an Win8 or Win8.1 (you did not specify). Have you checked your drivers config? If you save a config setting and then open the config page in "phone and modem" has it reset to default?
TAPI drivers default registry key for storing their config is here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Telephony
Some (not all) flavors/edition/versions of Windows 10 have removed the access rights to the registry key from the built-in system account that runs the telephony service.
I don't know about Cisco specifically, but we have encountered several TAPI drivers from various manufactures that "save" their settings without giving an error, but in fact have not changed because of this issue.
Open your services.msc and check the Telephony (TapiSrv) service account, then check if it has access to the registry key.
Recently I was trying to find answer to question "How to determine if current logged in user is part of domain or not"
On Stackoverflow I found pretty decent answers for the above which involved usage of
using System.Security.Principal;
using System.DirectoryServices.AccountManagement;
But I also see a simple solution saying
System.Environment.UserDomainName; - gives name of the current user's domain name.
System.Environment.MachineName; - gives name of the machine.
If above two are not the same means the user is part of domain returned by UserDomainName
Fair enough, also confirmed by this link from MSDN
Now the question is what if the "Domain name" and "Machine name" are identical?
or
Is it possible that a machine with the exact same name as domain name can join the domain?
If this is true, is there any possibilities to counter check this by adding something to this simple solution
I bet you the current logged on user does not have a distingished name if he or she isn't logged on to a domain. Use GetUserNameEx with the EXTENDED_NAME_FORMAT type NameFullyQualifiedDN (1).
If you get a value back then you know the current user is logged on to a domain. Though, Calling this function might block your program unexpectedly for a period of time. You probably want to call this function in a asynchronous fashion as it might atempt to connect to some Active Directory service and just eventually fail or timeout.
An yet more resilient way to accomplish this would be to look up the account SID and check whether the EqualPrefixSid can compare it with the machine. If this is the case, then you know the current account is local to the machine (i.e. not in a domain). This does not involve crossing the network and waiting for a timeout, so it's a more direct approach. Interestingly, it also implies that if the machine name is the same as the user domain, Windows would have to assume that the domain you want to logon on to is the local machine and it should therefore be almost impossible to logon to the actual domain if the machine name really is the same as the domain.
I am trying to run a file watcher over some server path using windows service.
I am using my windows login credential to run the service, and am able to access this "someServerPath" from my login.
But when I do that from the FileSystemWatcher it throws:
The directory name \someServerPath is invalid" exception.
var fileWatcher = new FileSystemWatcher(GetServerPath())
{
NotifyFilter=(NotifyFilters.LastWrite|NotifyFilters.FileName),
EnableRaisingEvents=true,
IncludeSubdirectories=true
};
public static string GetServerPath()
{
return string.Format(#"\\{0}", FileServer1);
}
Can anyone please help me with this?
I have projects using the FileSystemWatcher object monitoring UNC paths without any issues.
My guess from looking at your code example may be that you are pointing the watcher at the root share of the server (//servername/) which may not be a valid file system share? I know it returns things like printers, scheduled tasks, etc. in windows explorer.
Try pointing the watcher to a share beneath the root - something like //servername/c$/ would be a good test example if you have remote administrative rights on the server.
With regards to the updated question, I agree that you probably need to specify a valid share, rather than just the remote server name.
[Update] Fixed previous question about the exception with this:
specify the name as #"\\someServerPath"
The \ is being escaped as a single \
When you prefix the string with an # symbol, it doesn't process the escape sequences.
I was just asked this question in regards to FileSystemWatcher code running as a service and the issue is permissions. I searched and found this question and answer but unfortunately none of the answers here solved the problem. Anyway, I just solved it, so I thought I would throw in the solution here for next guy who searches and find this question.
The drive was mapped as a logged in user but the service was running as LocalSystem. LocalSystem is a different account and does not have access to drives mapped by a user.
The fix is to either:
Authenticate first (I use a C# Class to establish a network connection with credentials)
Run your service as a user that has access to the share.
You can test LocalSystem authentication by using a LocalSystem command prompt, see How to open a command prompt running as Local System?
Even though this is already answered I thought I would put in my two cents worth becaus eyou can see this same error even if you supply valid paths.
You will get the same error when the process running the watcher does not have access to the remote share. This will happen if the watcher is in a service running under the System account and the share is created by a user. System does not have access to that share and wont recognize it, you will need to impersonate the user to get access to it.
although you can use a FileWatcher over the network, you will have to account for other factors, like disconnection of the network share. If your connection to the share is terminated (maintenance, lag, equipment reset, etc) you will no longer have a valid handle on the share in your filewatcher
You can't use directory watches over network shares, this is a limitation of the OS, not of .NET.
Let me ask whether you can make a C# program which can not access to any local file system other than the folder/sub folders it is installed? And how if the answer is yes.
For details if it is necessary and possible, users are supposed to accept the program runs under a special user account which is restricted the file access only to the folder it is installed and to sub folders.
Thank you very much in advance.
Edit : Let me add context. I want users do not change their accounts. And as a programmer I do not have complete control over the program for some reasons.
Can you make a C# program which cannot access any part of the local file system other than the directory in which it is installed?
No, because every C# program will need to at the very least have access to the .NET runtime libraries, which are in the Windows install directory.
My suggestion to you is that you look into isolated storage. The .NET code access security system enables you to set a policy which states that certain programs only get to access the .NET runtime, the installed location of the code, and a special "isolated storage" directory that can be used for the application to store per-user data.
The answer is yes, but how you do this is complicated.
First, you need a user account with extremely limited permissions. It must be able to access files and run programs within the installation directory of the program, and that's pretty much it. You can create such a user with the installer program, using tools in the System.DirectoryServices namespace. Here's an example of creating a user:
using System.DirectoryServices;
using System.DirectoryServices.ActiveDirectory;
private void CreateUser(string userName, string password)
{
DirectorySearcher dseSearcher = new DirectorySearcher();
string rootDSE = dseSearcher.SearchRoot.Path;
string userDSE = rootDSE.Insert(7, "OU=Users,");
DirectoryEntry userDE = new DirectoryEntry(userDSE);
DirectoryEntry user = userDE.Children.Add("CN=" + userID, "user");
staff.Properties["samAccountName"].Value = userID;
staff.Properties["UserPrincipalName"].Value = userName +
#"#domain";
staff.CommitChanges();
staff.Properties["userAccountControl"].Value =
ActiveDs.ADS_USER_FLAG.ADS_UF_NORMAL_ACCOUNT |
ActiveDs.ADS_USER_FLAG.ADS_UF_DONT_EXPIRE_PASSWD;
staff.CommitChanges();
staff.Invoke("SetPassword", new Object[] { password });
}
Now, once that's happened, you need to make sure your program normally runs in the context of that user account. You can do that by specifying the user account to run the program with in a ProcessStartInfo object, used by a "bootstrapper" program that is what you create shortcuts for. You can then also ensure the program is running in the context of that user account using Environment.CurrentUser, and abort execution of the program if it is being run by any more permissive account.
If you just want to restrict the program to a particular account, you can look up the user's credentials, and exit the program if it's not the right one.
http://msdn.microsoft.com/en-us/library/csyx45b8.aspx
http://msdn.microsoft.com/en-us/library/sfs49sw0.aspx
I am trying to run a file watcher over some server path using windows service.
I am using my windows login credential to run the service, and am able to access this "someServerPath" from my login.
But when I do that from the FileSystemWatcher it throws:
The directory name \someServerPath is invalid" exception.
var fileWatcher = new FileSystemWatcher(GetServerPath())
{
NotifyFilter=(NotifyFilters.LastWrite|NotifyFilters.FileName),
EnableRaisingEvents=true,
IncludeSubdirectories=true
};
public static string GetServerPath()
{
return string.Format(#"\\{0}", FileServer1);
}
Can anyone please help me with this?
I have projects using the FileSystemWatcher object monitoring UNC paths without any issues.
My guess from looking at your code example may be that you are pointing the watcher at the root share of the server (//servername/) which may not be a valid file system share? I know it returns things like printers, scheduled tasks, etc. in windows explorer.
Try pointing the watcher to a share beneath the root - something like //servername/c$/ would be a good test example if you have remote administrative rights on the server.
With regards to the updated question, I agree that you probably need to specify a valid share, rather than just the remote server name.
[Update] Fixed previous question about the exception with this:
specify the name as #"\\someServerPath"
The \ is being escaped as a single \
When you prefix the string with an # symbol, it doesn't process the escape sequences.
I was just asked this question in regards to FileSystemWatcher code running as a service and the issue is permissions. I searched and found this question and answer but unfortunately none of the answers here solved the problem. Anyway, I just solved it, so I thought I would throw in the solution here for next guy who searches and find this question.
The drive was mapped as a logged in user but the service was running as LocalSystem. LocalSystem is a different account and does not have access to drives mapped by a user.
The fix is to either:
Authenticate first (I use a C# Class to establish a network connection with credentials)
Run your service as a user that has access to the share.
You can test LocalSystem authentication by using a LocalSystem command prompt, see How to open a command prompt running as Local System?
Even though this is already answered I thought I would put in my two cents worth becaus eyou can see this same error even if you supply valid paths.
You will get the same error when the process running the watcher does not have access to the remote share. This will happen if the watcher is in a service running under the System account and the share is created by a user. System does not have access to that share and wont recognize it, you will need to impersonate the user to get access to it.
although you can use a FileWatcher over the network, you will have to account for other factors, like disconnection of the network share. If your connection to the share is terminated (maintenance, lag, equipment reset, etc) you will no longer have a valid handle on the share in your filewatcher
You can't use directory watches over network shares, this is a limitation of the OS, not of .NET.