Delen via

Active Directory-geïntegreerde SQL Managed Instance implementeren die is ingeschakeld door Azure Arc

  • Artikel

In dit artikel leert u hoe u Azure SQL Managed Instance met Azure Arc implementeert met Active Directory-verificatie.

Vereisten

Voordat u begint met de implementatie van sql Managed Instance, moet u ervoor zorgen dat u aan de volgende vereisten voldoet:

Connectorvereisten

De door de klant beheerde keytab Active Directory-connector en de door het systeem beheerde keytab Active Directory-connector zijn verschillende implementatiemodi met verschillende vereisten en stappen. Elke modus heeft specifieke vereisten tijdens de implementatie. Selecteer het tabblad voor de connector die u gebruikt.

Voor een door de klant beheerde keytab-implementatie van Active Directory moet u het volgende opgeven:

  • Een Active Directory-gebruikersaccount voor SQL
  • Spn's (Service Principal Names) onder het gebruikersaccount
  • DNS A-record (doorsturen) voor het primaire eindpunt van SQL (en eventueel een secundair eindpunt)

Implementatie voorbereiden

Voer, afhankelijk van uw implementatiemodus, de volgende stappen uit om de implementatie van SQL Managed Instance voor te bereiden.

De implementatie voorbereiden in de door de klant beheerde keytab-modus:

  1. Identificeer een DNS-naam voor de SQL-eindpunten: kies unieke DNS-namen voor de SQL-eindpunten waarmee clients verbinding maken van buiten het Kubernetes-cluster.

    • De DNS-namen moeten zich in het Active Directory-domein of in de onderliggende domeinen bevinden.
    • De voorbeelden in dit artikel gebruiken sqlmi-primary.contoso.local voor de primaire DNS-naam en sqlmi-secondary.contoso.local voor de secundaire DNS-naam.

  2. Identificeer de poortnummers voor de SQL-eindpunten: voer een poortnummer in voor elk van de SQL-eindpunten.

    • De poortnummers moeten zich in het acceptabele bereik van poortnummers voor uw Kubernetes-cluster bevinden.
    • In de voorbeelden in dit artikel wordt gebruikgemaakt 31433 van het primaire poortnummer en 31434 voor het secundaire poortnummer.

  3. Maak een Active Directory-account voor het beheerde exemplaar: kies een naam voor het Active Directory-account dat uw beheerde exemplaar vertegenwoordigt.

    • De naam moet uniek zijn in het Active Directory-domein.
    • In de voorbeelden in dit artikel wordt gebruikgemaakt sqlmi-account van de naam van het Active Directory-account.

    Ga als volgende te werk om het account te maken:

    1. Open het hulpprogramma Active Directory op de domeincontroller. Maak een account voor het beheerde exemplaar.
    2. Voer een accountwachtwoord in dat voldoet aan het wachtwoordbeleid voor het Active Directory-domein. U gebruikt dit wachtwoord in een aantal van de stappen in de volgende secties.
    3. Zorg ervoor dat het account is ingeschakeld. Het account heeft geen speciale machtigingen nodig.

  4. DNS-records maken voor de SQL-eindpunten in de Active Directory DNS-servers: maak in een van de Active Directory DNS-servers A-records (forward lookup records) voor de DNS-naam die u in stap 1 hebt gekozen.

    • De DNS-records moeten verwijzen naar het IP-adres waarop het SQL-eindpunt luistert naar verbindingen van buiten het Kubernetes-cluster.
    • U hoeft geen PTR-records (Reverse LookUp Pointer) te maken in combinatie met de A-records.

  5. SPN's maken: voor SQL om Active Directory-verificatie te kunnen accepteren voor de SQL-eindpunten, moet u twee SPN's registreren in het account dat u in de vorige stap hebt gemaakt. Er moeten twee SPN's worden geregistreerd voor het primaire eindpunt. Als u Active Directory-verificatie voor het secundaire eindpunt wilt, moeten de SPN's ook worden geregistreerd voor het secundaire eindpunt.

    SPN's maken en registreren:

    1. Gebruik de volgende indeling om de SPN's te maken:

      MSSQLSvc/<DNS name>
MSSQLSvc/<DNS name>:<port>

    2. Voer op een van de domeincontrollers de volgende opdrachten uit om de SPN's te registreren:

      setspn -S MSSQLSvc/<DNS name> <account>
setspn -S MSSQLSvc/<DNS name>:<port> <account>

      Uw opdrachten kunnen eruitzien als in het volgende voorbeeld:

      setspn -S MSSQLSvc/sqlmi-primary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-primary.contoso.local:31433 sqlmi-account

    3. Als u Active Directory-verificatie op het secundaire eindpunt wilt, voert u dezelfde opdrachten uit om SPN's toe te voegen voor het secundaire eindpunt:

      setspn -S MSSQLSvc/<DNS name> <account>
setspn -S MSSQLSvc/<DNS name>:<port> <account>

      Uw opdrachten kunnen eruitzien als in het volgende voorbeeld:

      setspn -S MSSQLSvc/sqlmi-secondary.contoso.local sqlmi-account
setspn -S MSSQLSvc/sqlmi-secondary.contoso.local:31434 sqlmi-account

  6. Genereer een keytab-bestand met vermeldingen voor het account en SPN's: voor SQL om zichzelf te kunnen verifiëren bij Active Directory en verificatie van Active Directory-gebruikers te accepteren, geeft u een keytab-bestand op met behulp van een Kubernetes-geheim.

    • Het keytab-bestand bevat versleutelde vermeldingen voor het Active Directory-account dat wordt gegenereerd voor het beheerde exemplaar en de SPN's.

    • SQL Server gebruikt dit bestand als referentie voor Active Directory.

    • U kunt kiezen uit meerdere hulpprogramma's om een keytab-bestand te genereren:

      • adutil: Beschikbaar voor Linux (zie Inleiding tot adutil)
      • ktutil: Beschikbaar op Linux
      • ktpass: Beschikbaar in Windows
      • Aangepaste scripts

    Het keytab-bestand genereren dat specifiek is bedoeld voor het beheerde exemplaar:

    1. Gebruik een van deze aangepaste scripts:

      De scripts accepteren verschillende parameters en genereren een keytab-bestand en een YAML-specificatiebestand voor het Kubernetes-geheim dat de keytab bevat.

    2. Vervang in uw script de parameterwaarden door waarden voor de implementatie van uw beheerde exemplaar.

      Gebruik voor de invoerparameters de volgende waarden:

      • --realm: het Active Directory-domein in hoofdletters. Voorbeeld: CONTOSO.LOCAL
      • --account: Het Active Directory-account waar de SPN's zijn geregistreerd. Voorbeeld: sqlmi-account
      • --port: het primaire SQL-eindpuntpoortnummer. Voorbeeld: 31433
      • --dns-name: de DNS-naam voor het primaire SQL-eindpunt.
      • --keytab-file: het pad naar het keytab-bestand.
      • --secret-name: De naam van het keytab-geheim waarvoor een specificatie moet worden gegenereerd.
      • --secret-namespace: De Kubernetes-naamruimte die het keytab-geheim bevat.
      • --secondary-port: het poortnummer van het secundaire SQL-eindpunt (optioneel). Voorbeeld: 31434
      • --secondary-dns-name: De DNS-naam voor het secundaire SQL-eindpunt (optioneel).

      Kies een naam voor het Kubernetes-geheim dat als host fungeert voor de keytab. Gebruik de naamruimte waar het beheerde exemplaar is geïmplementeerd.

    3. Voer de volgende opdracht uit om een keytab te maken:

      AD_PASSWORD=<password> ./create-sql-keytab.sh --realm <Active Directory domain in uppercase> --account <Active Directory account name> --port <endpoint port> --dns-name <endpoint DNS name> --keytab-file <keytab file name/path> --secret-name <keytab secret name> --secret-namespace <keytab secret namespace>

      Uw opdracht ziet er mogelijk uit zoals in het volgende voorbeeld:

      AD_PASSWORD=<password> ./create-sql-keytab.sh --realm CONTOSO.LOCAL --account sqlmi-account --port 31433 --dns-name sqlmi.contoso.local --keytab-file sqlmi.keytab --secret-name sqlmi-keytab-secret --secret-namespace sqlmi-ns

    4. Voer de volgende opdracht uit om te controleren of de keytab juist is:

      klist -kte <keytab file>

  7. Implementeer het Kubernetes-geheim voor de keytab: gebruik het Kubernetes-specificatiebestand dat u in de vorige stap hebt gemaakt om het geheim te implementeren.

    Het specificatiebestand ziet er ongeveer als volgt uit:

    apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: <secret name>
  namespace: <secret namespace>
data:
  keytab: <keytab content in Base64>

    Voer deze opdracht uit om het Kubernetes-geheim te implementeren:

    kubectl apply -f <file>

    Uw opdracht kan er als volgt uitzien:

    kubectl apply -f sqlmi-keytab-secret.yaml

Eigenschappen instellen voor Active Directory-verificatie

Als u SQL Managed Instance wilt implementeren die is ingeschakeld door Azure Arc voor Azure Arc Active Directory-verificatie, werkt u uw implementatiespecificatiebestand bij om te verwijzen naar het exemplaar van de Active Directory-connector dat moet worden gebruikt. Als u verwijst naar de Active Directory-connector in het SQL-specificatiebestand, wordt SQL automatisch ingesteld voor Active Directory-verificatie.

Als u Active Directory-verificatie in sql wilt ondersteunen in de door de klant beheerde keytabmodus, stelt u de volgende eigenschappen in uw implementatiespecificatiebestand in. Sommige eigenschappen zijn vereist en sommige zijn optioneel.

Vereist

  • spec.security.activeDirectory.connector.name: De naam van de bestaande aangepaste resource van de Active Directory-connector die moet worden toegevoegd voor Active Directory-verificatie. Als u een waarde voor deze eigenschap invoert, wordt Active Directory-verificatie geïmplementeerd.
  • spec.security.activeDirectory.accountName: De naam van het Active Directory-account voor het beheerde exemplaar.
  • spec.security.activeDirectory.keytabSecret: De naam van het Kubernetes-geheim dat als host fungeert voor het vooraf gemaakte keytab-bestand voor gebruikers. Dit geheim moet zich in dezelfde naamruimte bevinden als het beheerde exemplaar. Deze parameter is alleen vereist voor de Active Directory-implementatie in de door de klant beheerde keytabmodus.
  • spec.services.primary.dnsName: Voer een DNS-naam in voor het primaire SQL-eindpunt.
  • spec.services.primary.port: Voer een poortnummer in voor het primaire SQL-eindpunt.

Optioneel

  • spec.security.activeDirectory.connector.namespace: De Kubernetes-naamruimte van de bestaande Active Directory-connector die moet worden toegevoegd voor Active Directory-verificatie. Als u geen waarde invoert, wordt de SQL-naamruimte gebruikt.
  • spec.services.readableSecondaries.dnsName: Voer een DNS-naam in voor het secundaire SQL-eindpunt.
  • spec.services.readableSecondaries.port: Voer een poortnummer in voor het secundaire SQL-eindpunt.

Uw implementatiespecificatiebestand voorbereiden

Bereid vervolgens een YAML-specificatiebestand voor om SQL Managed Instance te implementeren. Voer uw implementatiewaarden in het specificatiebestand in voor de modus die u gebruikt.

Notitie

In het specificatiebestand voor beide modi biedt de admin-login-secret waarde in het YAML-voorbeeld basisverificatie. U kunt de parameterwaarde gebruiken om u aan te melden bij het beheerde exemplaar en vervolgens aanmeldingen te maken voor Active Directory-gebruikers en -groepen. Zie Connect to Active Directory-geïntegreerde SQL Managed Instance ingeschakeld door Azure Arc voor meer informatie.

In het volgende voorbeeld ziet u een specificatiebestand voor de door de klant beheerde keytabmodus:

apiVersion: v1
data:
  password: <your Base64-encoded password>
  username: <your Base64-encoded username>
kind: Secret
metadata:
  name: admin-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v3
kind: SqlManagedInstance
metadata:
  name: <name>
  namespace: <namespace>
spec:
  backup:
    retentionPeriodInDays: 7
  dev: false
  tier: GeneralPurpose
  forceHA: "true"
  licenseType: LicenseIncluded
  replicas: 1
  security:
    adminLoginSecret: admin-login-secret
    activeDirectory:
      connector:
        name: <Active Directory connector name>
        namespace: <Active Directory connector namespace>
      accountName: <Active Directory account name>
      keytabSecret: <keytab secret name>
  services:
    primary:
      type: LoadBalancer
      dnsName: <primary endpoint DNS name>
      port: <primary endpoint port number>
    readableSecondaries:
      type: LoadBalancer
      dnsName: <secondary endpoint DNS name>
      port: <secondary endpoint port number>
  storage:
    data:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi
    logs:
      volumes:
      - accessMode: ReadWriteOnce
        className: local-storage
        size: 5Gi

Het beheerde exemplaar implementeren

Implementeer voor de door de klant beheerde keytabmodus en de door het systeem beheerde keytabmodus het beheerde exemplaar met behulp van het voorbereide YAML-bestand met specificatie:

  1. Sla het bestand op. In het voorbeeld in de volgende stap wordt sqlmi.yaml gebruikt voor de bestandsnaam van de specificatie, maar u kunt elke bestandsnaam kiezen.

  2. Voer de volgende opdracht uit om het exemplaar te implementeren met behulp van de specificatie:

    kubectl apply -f <specification file name>

    Uw opdracht ziet er mogelijk uit zoals in het volgende voorbeeld:

    kubectl apply -f sqlmi.yaml

Gerelateerde inhoud