Delen via

Inzicht in Active Directory-verificatie voor SQL Server in Linux en containers

  • Artikel

van toepassing op:SQL Server- - Linux

In dit artikel vindt u meer informatie over hoe Active Directory-verificatie werkt voor SQL Server die is geïmplementeerd in Linux of containers.

Concepten

Lightweight Directory Access Protocol (LDAP)

LDAP is een toepassingsprotocol voor het werken met verschillende adreslijstservices, waaronder Active Directory. Adreslijstservices slaan gebruikers- en accountgegevens en beveiligingsgegevens zoals wachtwoorden op. Deze informatie wordt versleuteld en vervolgens gedeeld met andere apparaten in het netwerk.

Zie LDAP-aanmelding inschakelen in Windows Servervoor meer informatie over het beveiligen van LDAP.

Kerberos

Kerberos is een verificatieprotocol dat wordt gebruikt om de identiteit van een gebruiker of hostcomputer te verifiëren. U kunt het beschouwen als een manier om de client en server te verifiëren.

Wanneer u werkt in een heterogene (gemengde) omgeving waarin u Windows- en niet-Windows-servers en -clients hebt, zijn er twee soorten bestanden die u nodig hebt om te werken met directoryservices op basis van Active Directory:

  • Keytab-bestanden (kort voor 'sleuteltabellen')
  • Kerberos-configuratiebestanden (krb5.conf of krb5.ini)

Wat is een keytab-bestand?

Serverprocessen op Linux- of Unix-systemen kunnen niet worden geconfigureerd voor het uitvoeren van processen met een Windows-serviceaccount. Wanneer u wilt dat een Linux- of Unix-systeem zich automatisch aanmeldt bij Active Directory bij het opstarten, moet u een keytab-bestand gebruiken.

Een keytab is een cryptografisch bestand met een weergave van een met Kerberos beveiligde service en de sleutel op lange termijn van de bijbehorende service-principalnaam in het KDC (Key Distribution Center). De sleutel is niet het wachtwoord zelf.

Keytabs worden gebruikt voor:

  • de service zelf verifiëren bij een andere service in het netwerk of
  • Ontsleutel het Kerberos-serviceticket van een binnenkomende directorygebruiker voor de service.

Wat is een krb5.conf-bestand?

Het /etc/krb5.conf-bestand (ook wel krb5.inigenoemd) biedt configuratie-invoer voor de KRB5-bibliotheken (Kerberos v5) en GNU Simple Authentication and Security Layer API (GSSAPI).

Deze informatie omvat het standaarddomein, eigenschappen van elk domein (zoals Sleuteldistributiecentra) en de standaardlevensduur van Kerberos-tickets.

Dit bestand is nodig om Active Directory-verificatie te laten werken. krb5.conf is een INI-bestand, maar elke waarde in het sleutel-waardepaar kan een subgroep zijn die is ingesloten door { en }.

Raadpleeg de krb5.confvoor meer informatie over het bestand .

Kerberos configureren voor SQL Server in Linux

Dit zijn de waarden die u nodig hebt op de hostserver waarop SQL Server op Linux wordt uitgevoerd. Als u andere (niet-SQL Server)-services hebt die op dezelfde host worden uitgevoerd, heeft uw krb5.conf bestand mogelijk nog enkele vermeldingen nodig.

Hier volgt een voorbeeldbestand krb5.conf ter referentie:

[libdefaults]
default_realm = CONTOSO.COM

[realms]
CONTOSO.COM = {
  kdc = adVM.contoso.com
  admin_server = adVM.contoso.com
  default_domain = contoso.com
}

[domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM

  • libdefaults: de default_realm-waarde moet aanwezig zijn. Met deze waarde wordt het domein opgegeven waartoe de hostmachine behoort.

  • realms (optioneel): voor elke realm kan de kdc waarde worden ingesteld om op te geven met welke sleuteldistributiecentra de computer contact moet opnemen bij het opzoeken van Active Directory-accounts. Als u meer dan één KDC hebt ingesteld, wordt de KDC voor elke verbinding geselecteerd door round robin.

  • domain_realm (optioneel): voor elke realm kunnen toewijzingen worden gegeven. Als dat niet zo is, gaat SQL Server in Linux ervan uit dat het domein contoso.com wordt toegewezen aan de realm CONTOSO.COM.

Het Kerberos-verificatieproces

Net als bij Kerberos-verificatie in Windows zijn de eerste twee stappen voor het verkrijgen van een tickettoekenningsticket (TGT) hetzelfde:

  • Een client begint het aanmeldingsproces door de gebruikersnaam en het wachtwoord (versleuteld) naar de domeincontroller (DC) te verzenden.

  • Nadat de gebruikersnaam en het wachtwoord zijn gecontroleerd op de interne opslag, retourneert de domeincontroller een TGT voor de gebruiker naar de client.

SQL Server op Linux gebruikt het keytab-bestand om het wachtwoord voor de SPN (Service Principal Name) te lezen en ontsleutelt vervolgens de versleutelde blob, die wordt gebruikt om de verbinding te autoriseren. In de volgende stappen wordt dit proces beschreven.

  • Zodra de gebruiker de TGT heeft, start de client een verbinding met SQL Server door de hostnaam en poort van het SQL Server-exemplaar op te geven.

  • De SQL-client maakt intern een Service Principal Name in de indeling MSSQLSvc/<host>:<port>. Dit is een in code vastgelegde indeling in de meeste SQL Server-clients.

  • De client start de Kerberos-handshake door een sessiesleutel aan te vragen bij de DC voor die SPN. Zowel de TGT als de SPN worden naar de DC verzonden.

diagram dat Active Directory-verificatie voor SQL Server op Linux laat zien - Ticket-Granting ticket en service-principalnaam verzonden naar de domeincontroller.

  • Nadat de DC de TGT en SPN heeft gevalideerd, wordt de sessiesleutel naar de client verzonden om verbinding te maken met de SQL Server SPN.

diagram met Active Directory-verificatie voor SQL Server in Linux: sessiesleutel geretourneerd naar client door DC.

  • De versleutelde blob van de sessiesleutel wordt naar de server verzonden.

diagram met Active Directory-verificatie voor SQL Server in Linux: sessiesleutel die naar de server wordt verzonden.

  • SQL Server leest het wachtwoord voor de SPN uit de keytab (mssql.keytab), een bestand op schijf met versleutelde tuples (SPN, wachtwoord).

  • SQL Server ontsleutelt de versleutelde blob van de client met het wachtwoord dat deze zojuist heeft opgezoekd, om de gebruikersnaam van de client op te halen.

  • SQL Server zoekt de client in de sys.syslogins tabel op om te controleren of de client is gemachtigd om verbinding te maken.

  • De verbinding wordt geaccepteerd of geweigerd.

diagram met Active Directory-verificatie voor SQL Server in Linux: geaccepteerde of geweigerde verbinding.

Kerberos configureren voor SQL Server-containers

Active Directory-verificatie voor SQL Server in containers is in feite hetzelfde als SQL Server in Linux. Het enige verschil is de SPN van de SQL Server-host. In het vorige scenario is de SPN MSSQLSvc/<host>:<port> omdat we verbinding maakten via de naam van de SQL Server-host. Nu moeten we echter verbinding maken met de container.

Voor SQL Server-containers kunt u het krb5.conf-bestand in de container maken. Het hostknooppunt waarop de container wordt uitgevoerd, hoeft geen deel uit te maken van het domein, maar moet wel verbinding kunnen maken met de domeincontroller waarmee de container verbinding probeert te maken.

Omdat we verbinding maken met een container, kan de servernaam in de clientverbinding afwijken van alleen de hostnaam. Dit kan de hostnaam, de containernaam of een andere alias zijn. Bovendien is er een goede kans dat de weergegeven poort voor SQL Server niet de standaard-1433is.

U moet de SPN gebruiken die is opgeslagen in mssql.keytab om verbinding te maken met de SQL Server-container. Als de SPN in mssql.keytab bijvoorbeeld is MSSQLSvc/sqlcontainer.domain.com:8000, gebruikt u sqlcontainer.domain.com,8000 als uw verbindingsreeks in de client (inclusief sqlcmd, SQL Server Management Studio en Azure Data Studio).

diagram met Active Directory-verificatie voor SQL Server-containers.

SQL Server-groep vernieuwen

U vraagt zich misschien af waarom er een gebruikersaccount in de keytab staat als u alleen een Service Principal Name nodig hebt om te verifiëren.

Stel dat u een gebruiker hebt adUser, die lid is van een groep adGroup. Als adGroup als login wordt toegevoegd aan SQL Server, betekent dit dat adUser ook toestemming heeft om in te loggen op het SQL Server-exemplaar. Hoewel adUser- nog steeds is verbonden met SQL Server, kan een domeinbeheerder adUser- verwijderen uit adGroup. Nu zou adUser niet meer gemachtigd moeten zijn om zich aan te melden bij SQL Server, maar ze hebben het Kerberos-verificatieproces al doorlopen en zijn verbonden.

We voeren periodiek een proces uit met de naam het vernieuwen van groepen om te beveiligen tegen een scenario waarin een verbonden gebruiker geen bevoegde actie meer mag uitvoeren (zoals het maken van een aanmelding of het wijzigen van een database).

SQL Server heeft een bevoegd Active Directory-account dat wordt gebruikt voor het vernieuwen van groepen. Dit account is geconfigureerd met behulp van mssql-conf- met de network.privilegedadaccount instelling, of standaard ingesteld op het computeraccount van de hostcomputer (<hostname>$).

De referenties voor het bevoegde account in mssql.keytab worden gebruikt voor het imiteren van de client (adUser in dit voorbeeld). SQL Server voert een Kerberos-handshake met zichzelf uit om de gegevens van het groepslidmaatschap te identificeren en vergelijkt deze met sys.syslogins om te controleren of adUser nog steeds over de benodigde machtigingen beschikt om verbinding te maken en de aangevraagde Transact-SQL opdrachten uit te voeren. Als adUser- is verwijderd uit adGroup-, wordt de verbinding beëindigd door SQL Server.

Voor het vernieuwen van groepen zijn de volgende twee voorwaarden vereist:

  • Netwerkverbinding tussen het SQL Server-exemplaar en het on-premises Active Directory-domein.
  • Tweerichtingsvertrouwen tussen het domein waarmee SQL Server is verbonden en het on-premises Active Directory-domein. Zie Understanding Active Directoryvoor meer informatie.

Verwante inhoud