Bug 13205 - Selecting Account is sensitive and cannot be delegated in Active Directory Users and Computers Account tab locks user out
Selecting Account is sensitive and cannot be delegated in Active Directory Us...
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
x86 All
: P5 normal
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2018-01-07 17:56 UTC by Antonios Kalkakos
Modified: 2018-01-22 12:17 UTC (History)
2 users (show)

See Also:

Patch for Samba 4.5.12 (675 bytes, patch)
2018-01-22 12:17 UTC, Antonios Kalkakos
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antonios Kalkakos 2018-01-07 17:56:39 UTC

I have an AD with two Debian Stretch Samba DCs. The Samba and heimdal-clients 7.1.0 packages are installed from Debian repositories. Management is done from MS-RSAT installed on a Windows 7 Pro client. 

When I select the option "Account is sensitive and cannot be delegated" (in Active Directory Users and Computers under the Account tab) for a user account regardless of its privileges, the user cannot login on any domain client PC (Windows 7 Pro or Linux).

Steps to Reproduce:

1) Login on the Windows 7 as domain admin and open Active Directory Users and Computers.
2) Right click on a domain user account (NOT the administrator, see later!), select the Account tab and check the option "Account is sensitive and cannot be delegated".
3) Log out and try to login with the user account credentials from step 2.

Actual Results:

The user cannot login. The respond is:
Windows 7 Pro: "Logon failure: user account restriction. Possible reasons are blank passwords are not allowed, logon hour restrictions, or a policy restriction has been enforced".
Debian Stretch: "You are not allowed to logon from this workstation". 

The user can login back normally by clearing the option "Account is sensitive and cannot be delegated".

Expected Results:

The user should login normally obtaining a non-forwardable TGT from the DC.

Additional Information:

Having already login on the Linux client (Debian Stretch in my case) with a local account and running the command kinit -F <the aforementioned username>, the Samba DC will provide a non-forwardable TGT. But running kinit -f <the aforementioned username> will again fail with the message "krb5_get_init_creds: Ticket may not be forwardable".

Investigation with Tcpdump and Wireshark showed that after receiving an AS-REQ for a TGT with the forwardable flag set, the Samba DC responds a KRB5KDC_ERR_POLICY with e-text "Ticket may not be forwardabale" (same as kinit -f). This behavior is correct according to CVE-2016-2125 (https://www.samba.org/samba/security/CVE-2016-2125.html) which states:

"0x00100000: UF_NOT_DELEGATED:
The UF_NOT_DELEGATED can be used to disable the ability to get forwardable TGT
for the account. It means the KDC will respond with an error if the client asks
for the forwardable ticket.  The client typically gives up and removes the
GSS_C_DELEG_FLAG flag and continues without passing delegated credentials.
Administrators can use this to disable possible delegation for the most
privileged accounts (e.g. administrator accounts)."

During the initial login however, both Samba and Windows 7 Pro clients will actually give up and not continue asking for a non-forwardable TGT, which means that the user will locked out. 

Testing with Wireshark on another (separate) AD with one Windows 2008 R2 DC showed that the DC ignored the forwardable flag on AS-REQ and the user logged in normally having a non-forwardable TGT. All subsequent TGS requests on the same login session from a Windows 7 client didn't have the forwardable flag set.
Comment 1 Antonios Kalkakos 2018-01-22 12:17:02 UTC
Created attachment 13917 [details]
Patch for Samba 4.5.12

I have prepared a patch for Samba 4.5.12 and will test it on the latest Samba 4.7.x in the next few days. It makes the AS to ignore the forwardable flag in TGT for accounts that must not be delegated, rather that replying with KRB_ERR message. Although only covers forwardable TGTs, I think the same should be done for proxiable TGTs. However, Microsoft seems to prefer forwadable over proxiable and (to the best of my knowledge) doesn't support postdatable tickets.

My tests involved a DC with two client PCs were successful achieving a similar behaviour to Windows 2008R2. The DC was a Debian Stretch with a patched Samba 4.5.12, the first client a fully updated Windows 7 Pro and the second a Debian Stretch with Samba 4.5.12 installed from the official repositories.

You may confirm and/or advise as I am neither a Kerberos nor a C guru :)