☰

Файлы в общей папке Azure можно открыть только для чтения в одном конкретном профиле в Windows 10 (DFS-N с аутентификацией на основе домена)

tag-icon • tag-icon azure kerberos windows-10 dfs azure-files
Файлы в общей папке Azure можно открыть только для чтения в одном конкретном профиле в Windows 10 (DFS-N с аутентификацией на основе домена)

[Я начну с объяснения того, как настроена среда] Для общего доступа к файлам мы используем сопоставление DFS-N, EX- \\Domain.local\Storageaccount. Это сопоставление размещено с ролью DFS-N на сервере Windows Server 2012 R2.

Например, на сервере DFS-N папка, с которой я работаю, на самом деле находится в Azure, - \\Domain.local\Storageaccount\FolderA\SubforbderB--> Эта папка имеет целевой объект, указывающий на \\storageaccount.file.core.windows.net.

Есть туннель к Azure. Аутентификация — это доменная аутентификация. Таким образом, пользователь получает доступ \\Domain.local\Storageaccount\к доменной аутентификации AD и возвращает билет Kerberos в файл Azure, а также аутентифицируется в Azure.

Теперь странность в том, что у меня есть обходной путь, который заключается в сопоставлении этой папки напрямую с путем к файловому ресурсу Azure вместо пути к AD \\storageaccount.file.core.windows.net\FolderA\SubforbderB— это сработало отлично, и пользователь может открыть файл с доступом на чтение и запись. Это означает, что проблема связана с аутентификацией AD. Эта проблема не возникает ни в одной другой папке, которая настроена таким же образом, но без наследования, ни у кого из других пользователей эта проблема не возникает.

[Теперь я объясню суть вопроса]

В настоящее время у нас есть папка \\Domain.local\Storageaccount\FolderA\SubforbderB - SubforbderB- в этой папке наследование отключено. Мы явно назначаем разрешения. У пользователя UserA возникли проблемы с доступом к файлам внутри папки \\Domain.local\Storageaccount\FolderA\SubforbderB, любой файл, который он открывает, открывается как доступный только для чтения. У пользователя UserA есть полный контроль в соответствии с ролями NTFS, а также IAM RBAC. Я проверил учетную запись пользователя UserA на другом компьютере и подтвердил, что у учетной записи есть доступ для чтения и записи. Я проверил учетную запись пользователя UserB с тем же доступом, что и у пользователя UserA, в другом профиле пользователя на том же компьютере с Windows 10, и пользователь UserB может получить доступ к файлам с доступом для чтения и записи. Это доказывает мне, что проблема связана с текущим профилем пользователя на компьютере с Windows 10.

Мы знаем, что мы можем просто пересоздать профиль на компьютере Windows, сделать резервную копию и восстановить данные, и эта проблема будет решена. Однако у пользователя много пользовательских конфигураций, и будет сложно перейти на новый профиль.

Мы работали с командами Microsoft Azure и Windows, и они не предлагают никаких решений, кроме повторного создания профиля.

Надеюсь, кто-то из вас уже сталкивался с этой проблемой и решил ее.

Вот что мы попробовали: очистить диспетчер учетных данных, повторно присоединиться к домену, SFC, сканирование DISM, обновления Windows, поискать в реестре все карты проводника файлов, очистить и их тоже.

Есть ли у вас какие-либо предложения, помимо пересоздания профиля пользователя Windows?

решение1

У нас был On-prem DC в этом месте, каким-то образом после того, как мы вывели этот DC из эксплуатации, теперь клиенты аутентифицируются напрямую с DC в Azure. Я повторно применил разрешение NTFS с помощью "ACCESS KEY". Теперь все работает так, как и ожидалось

решение2

Возможно, вам нужно назначить роль Azure RBAC Storage File Data Share Contributor или пользовательскую роль со следующими действиями с данными. Как показано ниже, для записи Microsoft.Storage/storageAccounts/fileServices/fileshares/files/write

{
  "assignableScopes": [
    "/"
  ],
  "description": "Allows for read, write, and delete access in Azure Storage file shares over SMB",
  "id": "/providers/Microsoft.Authorization/roleDefinitions/0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb",
  "name": "0c867c2a-1d8c-454a-a3db-ab2ea1bdc8bb",
  "permissions": [
    {
      "actions": [],
      "notActions": [],
      "dataActions": [
        "Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read",
        "Microsoft.Storage/storageAccounts/fileServices/fileshares/files/write",
        "Microsoft.Storage/storageAccounts/fileServices/fileshares/files/delete"
      ],
      "notDataActions": []
    }
  ],
  "roleName": "Storage File Data SMB Share Contributor",
  "roleType": "BuiltInRole",
  "type": "Microsoft.Authorization/roleDefinitions"
}

Кстати, для общих профилей пользователей я бы рекомендовал FSLogix. FSLogix использует контейнеры профилей для инкапсуляции профилей пользователей. Эти контейнеры динамически прикрепляются к сеансам пользователей, что позволяет пользователям иметь единообразный опыт в разных сеансах. Контейнеры профилей хранят пользовательские данные, конфигурации и настройки, сокращая время входа и повышая производительность.

PowerShell для получения ACL

# Specify the path to the file or folder
$path = "C:\Path\To\Your\FileOrFolder"

# Get the NTFS ACL
$ntfsAcl = Get-Acl -Path $path

# Display the NTFS ACL
Write-Host "NTFS ACL:"
$ntfsAcl | Format-List

Связанный контент