Assign Windows accounts and groups

With their Windows account, people sign in without storing a key or password: Access through the ODBC driver, and Excel and Power BI with the “Windows” authentication method. They get their permissions through their groups, just as they do elsewhere in Windows.

In the Zuordnungen (Assignments) area, on the Windows-Konten und -Gruppen (Windows accounts and groups) tab, you give an account or a group a rule. When you save, the service translates the name into its SID, so a group that's renamed later keeps its permissions.

1. Open Zuordnungen, tab Windows-Konten und -Gruppen.

2. Add one row per assignment:

   Column	What to enter
   Windows-Konto oder -Gruppe (Name oder SID) (Windows account or group (name or SID))	A group, for example CORP\Data-Readers, an account, or a SID. Enter built-in groups by their SID, for example S-1-5-32-545 for “Users”, because their names depend on the Windows display language
   Regel (Rule)	Pick a rule from the list, for example fachdaten-lesen

3. Leave the row. A name that Windows doesn't recognize is rejected.

The list is grouped by rule: each rule shows the accounts and groups that hold it. To group it differently, drag a column header into the bar above the list.

Result: Every member of the group can reach, with their Windows account, whatever the rule allows.

In the screenshot: (1) assignment of a Windows account to a rule.

• Permissions add up across all of an account's groups. Groups that Windows lists only for denying access (such as “Administrators” for a user who isn't elevated) don't count.
• Second factor and Windows: If the sign-in policy requires a code for Windows sign-ins, every person affected needs their own entry under Personen und Schlüssel (People and keys), with their account in the Windows-Konto (Windows account) field. A group has no second factor.
• Using the administration app with Windows: A group with the verwaltung rule lets its members use administration. Because of the default rule “Verwaltung nur mit zweitem Faktor” (Administration only with a second factor), each member also needs a person entry with their account and a second factor.
• Domain and Kerberos: Without an HTTP/<computer name> SPN for the service account, Windows falls back to NTLM, and sign-in still works. The administration app supports Windows sign-in with NTLM; it doesn't support running with Kerberos in a domain.
• Every new connection starts with an unauthenticated request, which appears in the audit as anonym … UNAUTHENTICATED (401). That's the first step of the protocol, not an error.

• Create a rule
• Set up database identities: give groups a shared SQL Server login
• Reference: HTTP: sign-in (reference), section “Sign-in with the Windows account” (data service documentation)