Отказано в доступе windows server 2012

I suggest restart Remote Desktop Licensing service on your RDS (don’t touch anything else if already been working which means you setup was ok)
and try to reconnect. If all ok then I suggest to check and reset the counter to your RDL with below ps1 script

Remote Desktop Licensing — Click To See Image

## This Script is intended to be used for Querying remaining time and resetting Terminal Server (RDS) Grace Licensing Period to Default 120 Days.
## Developed by Prakash Kumar ([email protected]) May 28th 2016
## www.adminthing.blogspot.com
## Disclaimer: Please test this script in your test environment before executing on any production server.
## Author will not be responsible for any misuse/damage caused by using it.

Clear-Host
$ErrorActionPreference = "SilentlyContinue"

## Display current Status of remaining days from Grace period.
$GracePeriod = (Invoke-WmiMethod -PATH (gwmi -namespace root\cimv2\terminalservices -class win32_terminalservicesetting).__PATH -name GetGracePeriodDays).daysleft
Write-Host -fore Green ======================================================
Write-Host -fore Green 'Terminal Server (RDS) grace period Days remaining are' : $GracePeriod
Write-Host -fore Green ======================================================  
Write-Host
$Response = Read-Host "Do you want to reset Terminal Server (RDS) Grace period to Default 120 Days ? (Y/N)"

if ($Response -eq "Y") {
## Reset Terminal Services Grace period to 120 Days

$definition = @"
using System;
using System.Runtime.InteropServices; 
namespace Win32Api
{
    public class NtDll
    {
        [DllImport("ntdll.dll", EntryPoint="RtlAdjustPrivilege")]
        public static extern int RtlAdjustPrivilege(ulong Privilege, bool Enable, bool CurrentThread, ref bool Enabled);
    }
}
"@ 

Add-Type -TypeDefinition $definition -PassThru

$bEnabled = $false

## Enable SeTakeOwnershipPrivilege
$res = [Win32Api.NtDll]::RtlAdjustPrivilege(9, $true, $false, [ref]$bEnabled)

## Take Ownership on the Key
$key = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey("SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod", [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::takeownership)
$acl = $key.GetAccessControl()
$acl.SetOwner([System.Security.Principal.NTAccount]"Administrators")
$key.SetAccessControl($acl)

## Assign Full Controll permissions to Administrators on the key.
$rule = New-Object System.Security.AccessControl.RegistryAccessRule ("Administrators","FullControl","Allow")
$acl.SetAccessRule($rule)
$key.SetAccessControl($acl)

## Finally Delete the key which resets the Grace Period counter to 120 Days.
Remove-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod'

write-host
Write-host -ForegroundColor Red 'Resetting, Please Wait....'
Start-Sleep -Seconds 10 

  }

Else 
    {
Write-Host
Write-Host -ForegroundColor Yellow '**You Chose not to reset Grace period of Terminal Server (RDS) Licensing'
  }

## Display Remaining Days again as final status
tlsbln.exe
$GracePost = (Invoke-WmiMethod -PATH (gwmi -namespace root\cimv2\terminalservices -class win32_terminalservicesetting).__PATH -name GetGracePeriodDays).daysleft
Write-Host
Write-Host -fore Yellow =====================================================
Write-Host -fore Yellow 'Terminal Server (RDS) grace period Days remaining are' : $GracePost
Write-Host -fore Yellow =====================================================

## Cleanup of Variables
Remove-Variable * -ErrorAction SilentlyContinue

Вместе с Dynamic Access Control в Windows Server 2012 появился интересный функционал, призванный облегчить разрешение проблем с доступом пользователей к файловым ресурсам. Этот функционал имеет название Access Denied Assistance, или помощь при отказе в доступе.

Стандартное сообщение, которое выдается пользователю при отказе в доступе, довольно неинформативно и не дает представления о том, что делать дальше. Получив такое сообщение, пользователь должен найти администратора, отвечающего за доступы и внятно объяснить, кто он такой, куда ему нужен доступ, и, главное, почему этот доступ должен быть ему предоставлен.

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

Access Denied Assistance как раз предназначен для разрешения подобных проблем. Он активируется на файловом сервере, и когда пользователь пытается получить доступ к ресурсу, ему будет показано специальное диалоговое окно, в котором можно запросить разрешение на доступ. Microsoft описывает несколько вариантов решения проблемы с доступом:

• Self-assistance (Помоги себе сам) — в этом варианте в окне содержится пошаговое описание процедуры получения доступа. Пользуясь этой информацией, пользователь самостоятельно запрашивает доступ к ресурсу;
• Assistance by the data owner (Помощь владельца ресурса) —  в этом случае отправляется уведомление владельцу файлового ресурса. Владелец принимает решение о предоставлении доступа и либо сам предоставляет соответствующие разрешения, либо обращается за помощью к администратору;
• Assistance by the server administrator (Помощь администратора сервера) — в том случае, если пользователь не смог решить проблему ни сам, ни с помощью владельца, можно настроить отправку сообщения администратору сервера.

Предварительные требования

Для включения Access Denied Assistance необходим файловый сервер Windows Server 2012 с установленными ролями File Server и File Server Resource Manager.

Для настройки Access Denied Assistance есть два способа — распространить настройки на все файловые сервера с помощью групповых политик либо произвести настройку каждого сервера отдельно из оснастки FSRM.

Групповые политики

Создаем новый объект групповой политики (или берем существующий) и открываем его в редакторе. Переходим в раздел Computer Configuration\Policies\Administrative Template\System\Access-Denied-Assistance, в котором находятся две политики:

1) Enable access-denied assistance on client for all file types — форсирует использование Access Denied Assistance на клиентской стороне, надо просто включить;
2) Customize message for Access Denied errors — отвечает за настройки Access Denied Assistance на файловых серверах, к которым применена данная политика.

Для настройки «Customize message for Access Denied errors» переводим ее в Enabled. Затем отмечаем чекбокс «Enable users to request assistance» и набираем текст, который увидит пользователь при отказе в доступе. Для удобства в тексте можно использовать специальные макросы:

[Original File Path] — путь к файлу;
[Original File Path Folder] — путь к родительской папке;
[Admin Email] — email администратора ресурса;
[Data Owner Email] — email владельца ресурса.

Должно получиться что то вроде: ″При проблеме с доступом к [Original File Path] обратитесь к администратору по адресу [Admin Email]″.

В разделе Email recipients указываем получателей сообщения. Можно выбрать владельца ресурса (Folder owner), администратора сервера (File server administrator), либо вручную ввести необходимые адреса email в поле «Additional recipients».

И в разделе Email Settings указываем, нужно ли включать в письмо утверждения для пользователей и устройств, а также надо ли делать соответствующие записи в системном журнале.

Созданные настройки надо применить к файловым серверам и к клиентским компьютерам. Тут есть выбор — создать один GPO и прилинковать его ко всему домену, или разнести  клиентские и серверные настройки по разным GPO и применять их к различным OU.

И еще. Для того, чтобы файловые сервера смогли отправлять почтовые сообщения, на них также необходимо произвести некоторые настройки. Для этого зайдем на сервер и выполним следующую команду PowerShell:

Set-FSRMSetting -SMTPServer ″mail.contoso.com″ -AdminEmailAddress ″admin@contoso.com″ -FromEmailAddress ″fsrm@contoso.com″

В этой команде мы указываем SMTP сервер mail.contoso.com, адрес администратора сервера admin@contoso.com и адрес отправителя fsrm@contoso.com.

Оснастка File System Resource Manager

Если вы хотите использовать для каждого сервера индивидуальные настройки, то можно воспользоваться оснасткой File System Resource Manager.

Для ее открытия надо нажать Win+R и ввести команду fsrm.msc (или из меню Tools в Server Manager). Открыв оснастку, кликаем правой клавишей на основном разделе и выбираем пункт Configure Options.

Переходим на вкладку Access-Denied Assistance, отмечаем чекбокс «Enable access-denied assistance» и вводим текст сообщения для пользователя. При составлении текста также можно использовать макросы, а внизу есть кнопка Preview, нажав которую можно посмотреть получившееся сообщение.

Затем жмем кнопку «Configure email requests», отмечаем чекбокс «Enable users to request assistance» и настраиваем дополнительные параметры: какую информацию надо включать в запрос, кому отправлять сообщение и надо ли делать запись о событии в системный журнал.

Теперь остается настроить параметры отправки почтовых сообщений. Это можно сделать как уже знакомой нам командой PowerShell, так и из оснастки FSRM. Переходим на вкладку Email Notifications и указываем SMTP сервер, который будет отправлять сообщение, а также адрес администратора сервера и адрес отправителя по умолчанию.

Для проверки можно воспользоваться кнопкой «Send Test Email». Если все данные были введены правильно, то на адрес администратора сервера будет отправлено тестовое сообщение.

После настройки Access Denied Assistance пользователь, не имеющий разрешений на доступ к ресурсу, получит вот такое сообщение. Как видите, теперь его не просто посылают на к администратору, а дают возможность самостоятельно запросить помощь по email либо воспользоваться запросом о помощи.

При нажатии на запрос помощи открывается форма, в которой пользователь может указать причину, по которой ему нужен доступ, и отправить сообщение администратору или владельцу ресурса (или обоим, в зависимости от настроек).

А вот так выглядит сообщение, полученное администратором сервера. В нем содержится вся необходимая информация: путь к ресурсу, имя пользователя и его текущие разрешения, утверждения для пользователя и устройства и описание проблемы самим пользователем. Все это поможет оперативно принять решение о предоставлении доступа.

По моему очень удобно, причем как для пользователя так и для администратора. А теперь о грустном 🙁 . Помощь при отказе в доступе работает только в том случае, если в качестве клиентской ОС используется Windows 8. Пользователи Windows 7 или XP увидят стандартное сообщение об ошибке, независимо от настроек на сервере. Впрочем, это еще один повод перейти на Windows 8.

На свеже установленной терминальной RDS ферме пользователи стали жаловаться, что при попытке открыть любой pdf документ с рабочего стола (локального диска) с помощью Adobe Reader 11 появляется ошибка «Произошла ошибка при открытии данного документа. Отказано в доступе». При этом при открытии это же документа из сетевой папки (шары) – проблемы не наблюдается (а это совсем уж странно, т.к. сетевая папка априори менее безопасный источник).

Проблема заключалась в том, что начиная с Adobe Reader 10, в Reader по-умолчанию включен Защищенный Режим (Protected Mode), позволяющий запретить пользователям открывать «неавторизованные» pdf файлы, тем самым защищая компьютер пользователя от потенциально вредоносных pdf-документов.

В том случае, если вы в большей степени доверяете источникам получения файлов, вовремя устанавливаете обновления и следите за актуальностью антивирусных баз, Защищенный режим можно отключить. Его можно отключить как персонально для пользователя в интерфейсе Adobe Reader Редактирование -> Установки -> Защита (повышенный уровень) -> снять галку у пункта Включить защищенный режим при запуске.

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

Отключить защищенный режим можно и из реестра.

для конкретного пользователя: нужно создать новый параметр с именем bProtectedMode в ветке реестра HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\11.0\Privileged со значением 0.

Создать параметр в реестре можно с помощью PowerShell. Команда будет следующая:

New-ItemProperty -Path "HKCU:\SOFTWARE\Adobe\Acrobat Reader\11.0\Privileged" –Name "bProtectedMode" -Value 0  -PropertyType "DWord"

для всех пользователей компьютера: в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown нужно также создать параметр bProtectedMode типа DWORD со значением 0.

New-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown" –Name "bProtectedMode" -Value 0  -PropertyType "DWord"

Эти настройки также можно распространить на компьютеры домена с помощью групповых политик (GPP). Для этого создайте новую политику GPO, назначьте ее на компьютеры пользователей, и в разделе Computer Configuration -> Preferences ->Windows Settings -> Registry создайте ключи:

для x64:

Keypath: HKLM\SOFTWARE\Wow6432Node\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown
Value name: bProtectedMode
Value type: REG_DWORD


Value data: 0

для x86

Keypath:          HKLM\SOFTWARE\Policies\Adobe\Acrobat Reader\11.0\FeatureLockDown
Value name:   bProtectedMode
Value type:     REG_DWORD
Value data:     0

После внесения изменений в реестре Adobe Reader нужно перезапустить.