Labels

admin (1) aix (1) alert (1) always-on (2) Architecture (1) aws (3) Azure (1) backup (3) BI-DWH (10) Binary (3) Boolean (1) C# (1) cache (1) casting (3) cdc (1) certificate (1) checks (1) cloud (3) cluster (1) cmd (7) collation (1) columns (1) compilation (1) configurations (7) Connection-String (2) connections (6) constraint (6) copypaste (2) cpu (2) csv (3) CTE (1) data-types (1) datetime (23) db (547) DB2 (1) deadlock (2) Denali (7) device (6) dotNet (5) dynamicSQL (11) email (5) encoding (1) encryption (4) errors (124) excel (1) ExecutionPlan (10) extended events (1) files (7) FIPS (1) foreign key (1) fragmentation (1) functions (1) GCP (2) gMSA (2) google (2) HADR (1) hashing (3) in-memory (1) index (3) indexedViews (2) insert (3) install (10) IO (1) isql (6) javascript (1) jobs (11) join (2) LDAP (2) LinkedServers (8) Linux (15) log (6) login (1) maintenance (3) mariadb (1) memory (4) merge (3) monitoring (4) MSA (2) mssql (444) mssql2005 (5) mssql2008R2 (20) mssql2012 (2) mysql (36) MySQL Shell (5) network (1) NoSQL (1) null (2) numeric (9) object-oriented (1) offline (1) openssl (1) Operating System (4) oracle (7) ORDBMS (1) ordering (2) Outer Apply (1) Outlook (1) page (1) parameters (2) partition (1) password (1) Performance (103) permissions (10) pivot (3) PLE (1) port (4) PostgreSQL (14) profiler (1) RDS (3) read (1) Replication (12) restore (4) root (1) RPO (1) RTO (1) SAP ASE (48) SAP RS (20) SCC (4) scema (1) script (8) security (10) segment (1) server (1) service broker (2) services (4) settings (75) SQL (74) SSAS (1) SSIS (19) SSL (8) SSMS (4) SSRS (6) storage (1) String (35) sybase (57) telnet (2) tempdb (1) Theory (2) tips (120) tools (3) training (1) transaction (6) trigger (2) Tuple (2) TVP (1) unix (8) users (3) vb.net (4) versioning (1) windows (14) xml (10) XSD (1) zip (1)
Showing posts with label MSA. Show all posts
Showing posts with label MSA. Show all posts

gMSA and SQL Server

 Overview for gMSA - see in this post.


gMSA and SQL Server
 A single gMSA can be shared across multiple SQL Server hosts.
It helps to manage the service accounts in environments with a large number of SQL Server instances, without compromise on security issues.
Any update to an MSA password does not require a restart of SQL Server.
gMSA can be very interesting for an availability group environment
  • The main point of gMSA for AG is the setup of one managed service account for all replicas.
  • All instances in AG should be in the gMSA group.
  • gMSA for AG is only supported from SQL Server 2016.

Connecting gMSA with SQL Server
A connection between SQL Server to gMSA is created by assigning the gMSA account to the SQL Server service.
The connection is done:
  • For a new installation: During the SQL Server installation you specify the gMSA account.
  • For an existing SQL Server instance: changing the existing SQL Server instance to use a gMSA is done with the SQL Server Configuration Manager (SSCM) tool.

gMSA requirements
gMSA requirements - see here.
Additional requirements for gMSA for SQL Server:
SQL Server 2014 and above
SQL Server support for gMSA when running on Windows Server 2012 R2 and above.
Domain Functional Level of 2012 or higher.
Active Directory PowerShell module installed.

Useful links

gMSA - Group Managed Service Account

Overview

Standalone MSA (Managed Service Account) is a type of managed domain account created and managed by the domain controller:
  • It’s assigned to a single member computer for use running a service.
  • The password is managed automatically by the domain controller.
  • You cannot use a MSA to log into a computer, but a computer can use a MSA to start a Windows service.
  • including delegation of management to other administrators.

gMSA (Group Managed Service Account) is the same as MSA but for a group:
  • A group = multiple servers.
  • Windows manages a service account for services running on a group of servers.
  • gMSA provide a single identity solution for services running on a server farm, or on systems behind Network Load Balance.
  • Active Directory automatically updates the group managed service account password without restarting services.
  • The service accounts can be used for scheduled tasks, IIS application pools, SQL Server and Microsoft Exchange.
  • Because gMSA can be used with multiple machines, it allows you the flexibility to be able to implement Network Load Balancing (NLB). NLB allows you to group together servers and operate as one single system.

Windows PowerShell commands are used to administer gMSA.

gMSA requirements
Windows Server 2012 and above.
A 64-bit architecture (required to run the PowerShell commands).
Domain Functional Level of 2012 or higher.
A Key Distribution Service root key (KDS root key) has to be created and 10 hours are required for it to be replicated on all domain controllers.

Useful links