CODEWITHSUNDEEP
c#sql-serverwindowsado.netiprincipal
mukesh singh
mukesh singh

Reputation: 21

How to Create New User under NT Authority\System the System in Window OS using C#

Right now my service is running under the NT Local system. I want to create the NTUser type to run the Service. I don't want to create Local system account. In the Service when u look some account running under NT Service__ . i also looking to create custom NT Service\CustomName user to run the Service.

Upvotes: 1

Views: 2640

Answers (2)

rjminchuk
rjminchuk

Reputation: 988

I am confused by your question, let me take a guess at what you might be trying to do: You are trying to use the built in [NT AUTHORITY\SYSTEM] account to authorize your application to other services.

Here's how I have used [NT AUTHORITY\SYSTEM] account with my C# MVC web applications to authorize access to a local sql server database.

.NET FRAMEWORK

// Views/Home/Index.cshtml
@ViewBag.Title="Home Page";

<div class="jumbotron">
    <h1>Hello @Model</h1>
    .....

// Controllers/HomeController.cs
using System.Data;
using System.Data.SqlClient;
using System.Web.Mvc;

public class HomeController : Controller
{
  private string _connStr = @"
    Database=MyDB;Integrated Security=true;";

  public ActionResult Index() 
  {
    using var conn = new SqlConnection(_connStr);
    conn.Open();
    var cmd = new SqlCommand(@"
      SELECT TOP 1 [name] FROM [dbo].[person];", conn);
    var reader = cmd.ExecuteReader();
    if (reader.Read())
      return View("index", reader["name"]);
    else
      throw new DataException("Nobody is in Person table!");
  }
}

SQL

IF NOT EXISTS(SELECT 1 FROM sys.syslogins WHERE name = 'NT AUTHORITY\SYSTEM')
BEGIN
    CREATE LOGIN [NT AUTHORITY\SYSTEM]
        FROM WINDOWS WITH DEFAULT_LANGUAGE = [us_english];

    GRANT CONNECT TO [NT AUTHORITY\SYSTEM];
END

IF NOT EXISTS(SELECT 1 FROM sys.sysusers WHERE name = 'NT AUTHORITY\SYSTEM')
BEGIN
    CREATE USER [NT AUTHORITY\SYSTEM] FOR LOGIN [NT AUTHORITY\SYSTEM];

    ALTER ROLE [db_reader] ADD MEMBER [NT AUTHORITY\SYSTEM];
END

IF NOT EXISTS(SELECT 1 FROM sys.tables WHERE name = 'person') 
BEGIN 
    CREATE TABLE [dbo].[person] (
        [id]   UNIQUEIDENTIFIER CONSTRAINT [DF_dbo.person_id] DEFAULT (NEWID()) ROWGUIDCOL NOT NULL,
        [name] NVARCHAR (50)    NULL,
        CONSTRAINT [PK_dbo.person] PRIMARY KEY CLUSTERED ([id] ASC)
    );

    INSERT INTO dbo.person
    SELECT NEWID(), 'BILLY'
END

IIS

Change the Default App Pool Application Pool to the LocalSystem identity, and Publish your .Net Framework MVC application to your C:\inetpub\wwwroot.

INTEGRATED SECURITY

You now have a web application running under the LocalSystem identity (NT AUTHORITY\SYSTEM), and have granted the built-in NT AUTHORITY\SYSTEM user access to connect to your database server. In SQL Server, you've created an NT AUTHORITY\SYSTEM user for your NT AUTHORITY\SYSTEM login. You've also granted that SQL user [db_reader] over your dbo schema.

WHY IS THIS IMPORTANT?

Integrated Security utilizes Kerberos Authentication to authenticate from Windows server to Windows server. In many organizations, Active Directory users are created to provide Identities for IIS Application Pools to access databases using Integrated Security.

Running an Application Pool under these AD accounts allows fine-grained control over what each application pool has access to. Additionally it prevents passwords from having to be incorporated into application configuration.

PROBLEMS WITH ACTIVE DIRECTORY IDENTITY USER APPROACH WHEN DEVELOPING LOCALLY

The problem with the AD Users being used for Identities is that you require access to Active Directory to mimic a production setup locally. You shouldn't have access to the passwords necessary to mimic the exact AD user based authentication, and you wouldn't want to use it anyways just in case you were accidentally targeting a production database. Worse, you may need to keep an entire development Domain in parity with a production domain to ensure you have access to all necessary AD Accounts.

Built-in auth is our "test double" for Active Directory. Utilizing the NT AUTHORITY\SYSTEM account, you shortcut Using Active Directory altogether, and keep all authentication local. Which is where development work should be done in the first place..

I like to treat integration testing more narrowly and test one integration point at a time by replacing separate services and databases with test doubles. Together with contract testing and running contract tests against test doubles as well as the real implementations you can come up with integration tests that are faster, more independent and usually easier to reason about.

- Martin Fowler: The Practical Test Pyramid

Now we can Debug (running Visual Studio as administrator), directly against IIS, with a "test double" for Active Directory authentication.

Upvotes: 0

Suresh Kaushik
Suresh Kaushik

Reputation: 77

So, your problem is creating an account or running the service dynamically under an account. If it is the latter, use Impersonation in C#.

Upvotes: 0

Related Questions