Skip to content

Commit 2f494c1

Browse files
b-ahibbardb-ahibbard
committed
kerberos doc
1 parent d566989 commit 2f494c1

File tree

1 file changed

+138
-8
lines changed

1 file changed

+138
-8
lines changed

‎articles/azure-netapp-files/kerberos.md

Lines changed: 138 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -100,7 +100,7 @@ Kerberos authentication is highly dependent on external services for proper func
100100
- Kerberos key distribution
101101
- Password services/single sign on
102102
- Identity services (such as LDAP)
103-
-
103+
104104
When using native Microsoft Active Directory (the only KDC type that Azure NetApp Files currently supports), then most of the external dependencies for Kerberos in Azure NetApp Files are covered, such as DNS, KDC, and password services. In some cases, required services may be hosted outside of the Active Directory domain (such as DNS). In those cases, it's important to ensure the required services are configured properly.
105105

106106
Azure NetApp Files has specific dependencies for properly functioning NFS Kerberos. Continue reading for more information.
@@ -172,10 +172,10 @@ New machine accounts are created when an Azure NetApp Files SMB volume is provis
172172
| --- | -------- |
173173
| First new SMB volume | New SMB machine account/DNS name |
174174
| Subsequent SMB volumes created in short succession from first SMB volume | Reused SMB machine account/DNS name (in most cases). |
175-
| Subsequent SMB volumes created much later than first SMB volume | Service determines if new machine account will be needed, but it is a possibility that multiple machine accounts can be created, which will create multiple IP address endpoints. |
175+
| Subsequent SMB volumes created much later than first SMB volume | The service determines if new machine account is needed, but it's possible multiple machine accounts can be created, which creates multiple IP address endpoints. |
176176
| First dual protocol volume | New SMB machine account/DNS name |
177177
| Subsequent dual protocol volumes created in short succession from first dual protocol volume | Re-used SMB machine account/DNS name (in most cases) |
178-
| Subsequent dual protocol volumes created much later than first dual protocol volume | Service determines if new machine account will be needed, but it is a possibility that multiple machine accounts can be created, which will create multiple IP address endpoints |
178+
| Subsequent dual protocol volumes created much later than first dual protocol volume | The service determines if a new machine account is needed, but it's possible multiple machine accounts can be created, which creates multiple IP address endpoints |
179179
| First SMB volume created after dual protocol volume | New SMB machine account/DNS name |
180180
| First dual protocol volume created after SMB volume | New SMB machine account/DNS name |
181181

@@ -202,9 +202,7 @@ The following diagram illustrates how an SMB Kerberos SPN is created when an Azu
202202

203203
<!-- Azure SMB -->
204204

205-
You can also view and manage properties with the `setspn` command.
206-
207-
It can also be viewed and managed using the setspn command.
205+
You can also view and manage properties with the [`setspn` command](/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241(v=ws.11)).
208206

209207
<!-- setspn command -->
210208

@@ -216,6 +214,138 @@ In most cases, knowing detailed steps in depth isn't be necessary for day-to-day
216214

217215
#### Detailed steps
218216

219-
For detailed steps about how an SMB machine account is created in Azure NetApp Files, expand the list below.
220-
<!-- collapsible -->
217+
<details>
218+
<summary>For detailed steps about how an SMB machine account is created in Azure NetApp Files, expand the list below.</summary>
219+
220+
- DNS lookup is performed using the DNS configuration for the SRV record of a Kerberos KDC. Aure NetApp Files uses the following SRV records in its requests.
221+
- `_kerberos._tcp.dc._msdcs.CONTOSO.COM`
222+
- `_kerberos._tcp.CONTOSO.COM` (if previous query returns no results)
223+
- DNS lookup is performed using the hostnames that are returned in the SRV query for the A/AAAA records of the KDCs.
224+
- An [LDAP ping](https://learn.microsoft.com/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9) (LDAP bind and [RootDSE](/windows/win32/adschema/rootdse) query) is performed to search for available legacy [NetLogon](/openspecs/windows_protocols/ms-nrpc/ff8f970f-3e37-40f7-bd4b-af7336e4792f) servers using the query (`&(DnsDomain=CONTOSO.COM)(NtVer=0x00000016)`) with an attribute filter for NetLogon. Newer Windows domain controller versions (greater than 2008) don't have the [`NtVer` value](/openspecs/windows_protocols/ms-adts/8e6a9efa-6312-44e2-af12-06ad73afbfa5) present.
225+
- A DNS query is performed by Azure NetApp Files to find the LDAP servers in the domain using the following SRV records:
226+
- `_ldap._tcp.CONTOSO.COM`
227+
- `_kerberos._tcp.CONTOSO.COM`
228+
>[!NOTE]
229+
>These queries occur multiple times in the same call over different portions of the process. DNS issues can create slowness in these calls or, with timeouts, complete failures.
230+
- If the queries fail to find an entry or if the entries found can't be contacted, SMB volume creation fails.
231+
- If the DNS queries succeed, then the next steps are processed.
232+
- ICMP (ping) is sent to check that the IP addresses returned from DNS are reachable.
233+
- If ping is blocked on the network by firewall policies, then the ICMP request fails. Instead, LDAP pings are used.
234+
- Another LDAP ping is performed to search for available legacy NetLogon servers using the query (`&(&(DnsDomain=CONTOSO.COM)(Host=KDChostname.contoso.com))(NtVer=0x00000006)`) with the attribute filter NetLogon. Newer Windows domain controller versions (greater than 2008) don't have the [NtVer](/openspecs/windows_protocols/ms-adts/8e6a9efa-6312-44e2-af12-06ad73afbfa5) value present.
235+
- An AS-REQ authentication is sent from the Azure NetApp Files service using the username configured with the Active directory connection.
236+
- The DC responds with `KRB5KDC_ERR_PREAUTH_REQUIRED`, which is asking the service to send the password for the user securely.
237+
- A second AS-REQ is sent with the [pre-authentication data](https://datatracker.ietf.org/doc/html/rfc6113) needed to authenticate with the KDC for access to proceed with machine account creation. If successful, a Ticket Granting Ticket (TGT) is sent to the service.
238+
- If successful, a TGS-REQ is sent by the service to request the CIFS service ticket (cifs/kdc.contoso.com) from the KDC using the TGT received in the AS-REP.
239+
- A new LDAP bind using the CIFS service ticket is performed. A series of queries are sent from Azure NetApp Files:
240+
- RootDSE base search for the ConfigurationNamingContext DN of the domain
241+
- OneLevel search of CN=partitions in the DN retrieved for the ConfigurationNamingContext using the filter (`&(&(objectClass=crossRef)(nETBIOSName=*))(dnsRoot=CONTOSO.COM)`) for the attribute NETBIOSname.
242+
- A base search using the filter (`|(objectClass=organizationalUnit)(objectClass=container)`) is performed on the OU specified in the Active Directory connections configuration. If none are specified, the default `OU=Computers` is used. This verifies the container exists.
243+
- A subtree search is performed on the base DN of the domain using the filter (`sAMAccountName=ANF-XXXX$`) to check if the account exists already.
244+
- If the account exists, it's reused.
245+
- If the account doesn't exist, it's created, provided the user has permissions to create and modify objects in the container using an `addRequest` LDAP command. The LDAP following attributes are set on the account:
246+
247+
| Attribute | Value |
248+
| - | - |
249+
| CN | ANF-XXXX |
250+
| `sAMAccountName` | ANF-XXXX$ |
251+
| `objectClass` | <ul><li>Top</li><li>Person</li><li>OrganizationalPerson</li><li>User</li><li>Computer</li></ul> |
252+
| `servicePrincipalName` | <ul><li>HOST/ANF-XXXX</li><li>HOST/anf-xxxx.contoso.com</li><li>CIFS/anf-xxxx.contoso.com</li></ul>
253+
| `userAccountControl` | 4096 |
254+
| operatingSystem | NetApp Release |
255+
| `dnsHostName` | ANF-XXXX.CONTOSO.COM |
256+
257+
- If the `addRequest` fails, the volume creation fail. An `addRequest` can fail due to incorrect permissions on the container object.
258+
- If the `addRequest` succeeds, an LDAP search using the filter (`sAMAccountName=ANF-XXXX$`) is performed to retrieve the the objectSid attribute.
259+
- An SMB2 "Negotiate protocol" conversation is performed to retrieve the supported Kerberos mechTypes from the KDC.
260+
- An SMB2 "Session setup" using the CIFS SPN and highest supported `mechType` and a "Tree connect" to IPC$ is performed.
261+
- An SMB2 `lsarpc` file is created in the IPC$ share.
262+
- A bind to DCERPC is performed. The the `lsarpc` file is written then read.
263+
- The following LSA requests are then performed:
264+
- `Lsa_openpolicy2`
265+
- `Lsa_lookupsids2`
266+
- A TGS-REQ using the TGT is performed to retrieve the ticket for the `kadmin/changepw` SPN that's associated with the `krbtgt` account.
267+
- A KPASSWD request is made from the service to the KDC to change the machine account password.
268+
- An LDAP query is performed with the filter (`sAMAccountName=ANF-XXXX`) for the attributes `distinguishedName` and `isCriticalSystemObject`.
269+
- If the account's `isCriticalSystemObject` is false (the default), the retrieved DN is used to formulate a `modifyRequest` to the attribute `msDs-SupportedEncryptionTypes`. This value is set to 30, which equates to `DES_CBC_MD5 (2) + RC4 (4) + AES 128 (8) + AES 256 (16)`.
270+
- A second "Negotiate protocol"/Kerberos ticket exchange/"Session setup"/"Tree connect" to IPC$ is performed. The SMB server’s machine account (ANF-XXXX$) serves as the Kerberos principal.
271+
- NETLOGON, NetrServer ReqChallenge/Authenticate2 communications are completed.
272+
- A third "Negotiate protocol:/Kerberos ticket exchange/"Session setup"/"Tree connect" to IPC$ is performed; the SMB server’s machine account (ANF-XXXX$) is used as the Kerberos principal.
273+
- Both `lsarpc` and `netlogon` connections are made as a final check of the account.
274+
</details>
275+
276+
## SMB share connection workflow (Kerberos)
277+
278+
When an Azure NetApp Files volume is mounting using Kerberos, a Kerberos ticket exchange is used during multiple session setup requests to provide secure access to the share. In most cases, knowing detailed steps in depth isn't necessary for day-to-day administration tasks. This knowledge is useful in troubleshooting failures when attempting to access an SMB volume in Azure NetApp Files.
279+
280+
<details>
281+
<summary>For steps detailing how SMB share is accessed in Azure NetApp Files, expand the list.</summary>
282+
- The client attempts to access an SMB share using the UNC path shown in Azure NetApp Files. By default, the UNC path would include the SMB server name (such as ANF-XXXX)
283+
- DNS is queried to map the hostname to an IP address
284+
- An initial SMB2 “Negotiate Protocol” conversation takes place
285+
o A request is sent from the client to discover which SMB dialects are supported by the server and includes what the requesting client supports
286+
o The server responds with what it supports, including:
287+
 Security mode (signing or not)
288+
 SMB version
289+
 Server GUID
290+
 Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
291+
 Max transaction size
292+
 Max read/write size
293+
 Security blob (Kerberos or NTLM)
294+
- A 2nd SMB2 “Negotiate Protocol” conversation takes place as “pre-authorization”/login
295+
o Request from client includes:
296+
 Preauthorization hash
297+
 Supported security modes (signing or not)
298+
 Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
299+
 Client GUID
300+
 Supported SMB dialects
301+
o If the preauthorization hash is accepted, the server responds with:
302+
 Security mode (signing or not)
303+
 Capabilities supported (DFS, leasing, large MTU, multichannel, persistent handles, directory leasing, encryption)
304+
 Max transaction size
305+
 Max read/write size
306+
 Security blob (Kerberos or NTLM)
307+
 SMB preauth integrity and encryption capabilities
308+
- If the protocol negotiation succeeds, a “Session setup” request is made
309+
o Setup uses the preauth hash from the protocol negotiation
310+
o Setup informs the SMB server what the requesting client supports, including:
311+
 StructureSize
312+
 Session binding flag
313+
 Security mode (Signing enabled/required)
314+
 Capabilities
315+
 Supported Kerberos encryption types
316+
- A “Session setup” response is sent
317+
o SMB credits are granted
318+
o Session ID is established
319+
o Session flags are set (guest, null, encrypt)
320+
o Kerberos encryption type is defined
321+
- A tree connect request is sent by the client for connection to the SMB share
322+
o Share flags/capabilities are sent from server, along with share permissions
323+
- The ioctl command FSCTL_QUERY_NETWORK_INTERFACE_INFO is sent to get the IP address of the SMB server
324+
o The SMB server in Azure NetApp Files reports back with the network information, including:
325+
 IP address
326+
 Interface capability (RSS on or off)
327+
 RSS queue count
328+
 Link speed
329+
- A tree connect request is sent by the client for connection to the IPC$ administrative share
330+
o The ipc$ share is a resource that shares the named pipes that are essential for communication between programs. The ipc$ share is used during remote administration of a computer and when viewing a computer's shared resources. You cannot change the share settings, share properties, or ACLs of the ipc$ share. You also cannot rename or delete the ipc$ share.
331+
o A file named srvsvc is created in the share as a service handle
332+
- A DCERPC bind is done to the srvsvc file to establish a secure connection
333+
o The file is written to with the previously retrieved information
334+
- A Kerberos TGS-REQ is issued by the Windows client to the KDC to get a service ticket (ST) for the SMB service
335+
- NetShareGetInfo command is run by the SMB client to the server and a response is sent
336+
- The SMB service ticket is retrieved from the KDC
337+
- Azure NetApp Files attempts to map the Windows user requesting access to the share to a valid UNIX user
338+
o A Kerberos TGS request is made using the SMB server Kerberos credentials stored with the SMB server’s keytab from initial SMB server creation to use for an LDAP server bind
339+
o LDAP is searched for a UNIX user that is mapped to the SMB user requesting share access. If no UNIX user exists in LDAP, then the default UNIX user “pcuser” is used by Azure NetApp Files for name mapping (files/folders written in dual protocol volumes will use the mapped UNIX user as the UNIX owner)
340+
- Another negotiate protocol/session request/tree connect is performed, this time using the SMB server’s Kerberos SPN to the Active Directory DC’s IPC$ share
341+
o A named pipe is established to the share via the srvsvc
342+
o A netlogon session is established to the share and the Windows user is authenticated
343+
- If permissions allow it for the user, the share lists the files and folders contained in the volume
344+
345+
>[!NOTE]
346+
>Azure NetApp Files adds entries to the Kerberos context cache for the client. These entries reside in the cache for the duration of the life of the Kerberos ticket (set by the KDC and controlled by the [Kerberos policy](/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/kerberos-policy)).
347+
</details>
348+
349+
221350

351+

0 commit comments

Comments
 (0)