Bug 1852080

Summary: missing documentation for required AD rights for adcli join and net join
Product: Red Hat Enterprise Linux 8 Reporter: NIST 184 Admin <unixhosting>
Component: adcliAssignee: Sumit Bose <sbose>
Status: CLOSED ERRATA QA Contact: shridhar <sgadekar>
Severity: high Docs Contact:
Priority: unspecified    
Version: 8.0CC: dlavu, sgadekar, sgoveas, unixhosting
Target Milestone: rcKeywords: Documentation, Improvement
Target Release: 8.0   
Hardware: x86_64   
OS: All   
Whiteboard: sync-to-jira
Fixed In Version: adcli-0.8.2-8.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-05-18 14:57:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description NIST 184 Admin 2020-06-29 17:12:24 UTC 
Description of problem:

adcli requires the specified user to have delegated rights in the AD domain in order to establish the machine password, create the computer object, etc. The documentation does not specify what delegated rights are required in Active Directory. It should not be assumed that Linux admins have full domain administrative rights, therefore the docs should specify which rights are necessary without having full domain admin rights.

realm join --membership-software=adcli ...



net (samba) joins appear to have different (fewer) rights requirements than adcli joins.

realm join --membership-software=samba ...


In RHEL7 and prior, the default realm join behavior selected samba. In RHEL8 the default realm join behavior selects adcli. The rights granted to my user in AD for samba joins do not appear to provide the rights necessary for a successful adcli join.


The documentation for realm, net, acli need to specify what delegated rights the --user= user must have to complete a successful join, for the computer maintain its membership, and later for the --user to remove from the domain and delete the computer object. If different rights are required for net vs adcli, the documentation must specify the needed rights in Active Directory for each one.


Version-Release number of selected component (if applicable):


How reproducible:

100% if I do not specify membership-software=samba that realm defaults to adcli in RHEL8.

Steps to Reproduce:
1. Log into RHEL 8 system
2. sudo to root user account
3. realm join --computer-ou=<myOU> --computer-name=<myComputer> --user=<myADuser> <myADrealm>

Actual results:

The realm attempts to join with adcli


Expected results:

The 'realm join' command attempts to join with samba (based on RHEL7 behavior)


Additional info:

Documentation
Comment 3 Sumit Bose 2020-11-11 10:56:41 UTC 
Upstream:
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/fa5c5fb4f8e7bcadf3e5a3798bd060720fd35eaa
Comment 6 shridhar 2020-11-18 19:30:22 UTC 
Tested with following data:

adcli-0.8.2-8.el8.x86_64

O]# rpm -Uvh adcli-0.8.2-8.el8.x86_64.rpm 
Verifying...                          ################################# [100%]
Preparing...                          ################################# [100%]
Updating / installing...
   1:adcli-0.8.2-8.el8                ################################# [ 50%]
Cleaning up / removing...
   2:adcli-0.8.2-7.el8                ################################# [100%]


]$ man adcli:
<snip>
DELEGATED PERMISSIONS
       It is common practice in AD to not use an account from the Domain Administrators group to join a machine to a domain but use a dedicated account which only has
       permissions to join a machine to one or more OUs in the Active Directory tree. Giving the needed permissions to a single account or a group in Active Directory
       is called Delegation. A typical example on how to configured Delegation can be found in the Delegation section of the blog post Who can add workstation to the
       domain[1].

       When using an account with delegated permissions with adcli basically the same applies as well. However some aspects are explained here in a bit more details to
       better illustrate different concepts of Active Directory and to make it more easy to debug permissions issues during the join. Please note that the following is
       not specific to adcli but applies to all applications which would like to modify certain properties or objects in Active Directory with an account with limited
       permissions.

       First, as said in the blog post it is sufficient to have "Create computer object" permissions to join a computer to a domain. But this would only work as
       expected if the computer object does not exist in Active Directory before the join. Because only when a new object is created Active Directory does not apply
       additional permission checks on the attributes of the new computer object. This means the delegated user can add any kind of attribute with any value to a new
       computer object also long as they meet general constraints like e.g. that the attribute must be defined in the schema and is allowed in a objectclass of the
       object, the value must match the syntax defined in the schema or that the sAMAccountName must be unique in the domain.

       If you want to use the account with delegated permission to remove computer objects in Active Directory (adcli delete-computer) you should of course make sure
       that the account has "Delete computer object" permissions.

       If the computer object already exists the "Create computer object" permission does not apply anymore since now an existing object must be modified. Now
       permissions on the individual attributes are needed. e.g.  "Read and write Account Restrictions" or "Reset Password". For some attributes Active Directory has
       two types of permissions the plain "Read and Write" permissions and the "Validated Write" permissions. For the latter case there are two specific permissions
       relevant for adcli, namely

       ·   Validated write to DNS host name

       ·   Validated write to service principal name

       Details about the validation of the values can be found in the "Validated Writes" section of [MS-ADTS], especially dNSHostName[2] and servicePrincipalName[3]. To
       cut it short for "Validated write to DNS host name" the domain part of the fully-qualified hostname must either match the domain name of the domain you want to
       join to or must be listed in the msDS-AllowedDNSSuffixes attribute. And for "Validated write to service principal name" the hostname part of the service
       principal name must match the name stored in dNSHostName or some other attributes which are not handled by adcli. This also means that dNSHostName cannot be
       empty or only contain a short name if the service principal name should contain a fully-qualified name.

       To summarize, if you only have validated write permissions you should make sure the domain part of the hostname matches the domain you want to join or use the
       --host-fqdn with a matching name.
       The plain read write permissions do not run additional validations but the attribute values must still be in agreement with the general constraints mentioned
       above. If the computer object already exists adcli might need the following permissions which are also needed by Windows clients to modify existing attributes:

       ·   Reset Password

       ·   Read and write Account Restrictions

       ·   Read and (validated) write to DNS host name

       ·   Read and (validated) write to service principal name

       additionally adcli needs

       ·   Read and write msDS-supportedEncryptionTypes

       This is added for security reasons to avoid that Active Directory stores Kerberos keys with (potentially weaker) encryption types than the client supports since
       Active Directory is often configured to still support older (weaker) encryption types for compatibility reasons.

       All other attributes are only set or modified on demand, i.e. adcli must be called with an option the would set or modify the given attribute. In the following
       the attributes adcli can modify together with the required permissions are listed:

       ·   userPrincipalName

           ·   Read/Write userPrincipal Name

       ·   msDS-supportedEncryptionTypes

           ·   Read/Write msDS-SupportedEncryptionTypes

       ·   dNSHostName

           ·   Read/Write dNSHostName

           ·   Read and write DNS host name attributes

           ·   Validated write to DNS host name
     ·   servicePrincipalName

           ·   Read/Write servicePrincipalName

           ·   Validated write to service principal name

       ·   operatingSystem

           ·   Read/Write Operating System

       ·   operatingSystemVersion

           ·   Read/Write Operating System Version

       ·   operatingSystemServicePack

           ·   Read/Write operatingSystemServicePack

       ·   userAccountControl

           ·   Read/Write userAccountControl

       ·   description

           ·   Read/Write Description

       For the management of users and groups (adcli create-user, adcli delete-user, adcli create-group, adcli delete-group) the same applies only for different types
       of objects, i.e. users and groups. Since currently adcli only supports the creation and the removal of user and group objects it is sufficient to have the
       "Create/Delete User objects" and "Create/Delete Group objects" permissions.

       If you want to manage group members as well (adcli add-member, adcli remove-member) "Read/Write Members" permissions are needed as well.

       Depending on the version of Active Directory the "Delegation of Control Wizard" might offer some shortcuts for common task like e.g.

       ·   Create, delete and manage user accounts

       ·   Create, delete and manage groups

       ·   Modify the membership of a group
       The first 2 shortcuts will provided full access to user and group objects which, as explained above, is more than currently is needed. After using those shortcut
       it is a good idea to verify in the "Security" tab in the "Properties" of the related Active Directory container that the assigned permissions meet the
       expectations.

BUGS
       Please send bug reports to either the distribution bug tracker or the upstream bug tracker at
       https://bugs.freedesktop.org/enter_bug.cgi?product=realmd&component=adcli

SEE ALSO
       realmd(8), net(8), sssd(8)

       Further details available in the realmd online documentation at http://www.freedesktop.org/software/realmd/

NOTES
        1. Who can add workstation to the domain
           https://docs.microsoft.com/en-us/archive/blogs/dubaisec/who-can-add-workstation-to-the-domain

        2. dNSHostName
           https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5c578b15-d619-408d-ba17-380714b89fd1

        3. servicePrincipalName
           https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/28ca4eca-0e0b-4666-9175-a37ccb8edada



Marking verified
Comment 7 shridhar 2020-11-30 14:19:08 UTC 
JfW]# rpm -q adcli
adcli-0.8.2-8.el8.x86_64


]# man adcli

<snip>

DELEGATED PERMISSIONS
       It is common practice in AD to not use an account from the Domain Administrators group to join a machine to a domain but use a dedicated account which only has
       permissions to join a machine to one or more OUs in the Active Directory tree. Giving the needed permissions to a single account or a group in Active Directory
       is called Delegation. A typical example on how to configured Delegation can be found in the Delegation section of the blog post Who can add workstation to the
       domain[1].

       When using an account with delegated permissions with adcli basically the same applies as well. However some aspects are explained here in a bit more details to
       better illustrate different concepts of Active Directory and to make it more easy to debug permissions issues during the join. Please note that the following is
       not specific to adcli but applies to all applications which would like to modify certain properties or objects in Active Directory with an account with limited
       permissions.

       First, as said in the blog post it is sufficient to have "Create computer object" permissions to join a computer to a domain. But this would only work as
       expected if the computer object does not exist in Active Directory before the join. Because only when a new object is created Active Directory does not apply
       additional permission checks on the attributes of the new computer object. This means the delegated user can add any kind of attribute with any value to a new
       computer object also long as they meet general constraints like e.g. that the attribute must be defined in the schema and is allowed in a objectclass of the
       object, the value must match the syntax defined in the schema or that the sAMAccountName must be unique in the domain.

       If you want to use the account with delegated permission to remove computer objects in Active Directory (adcli delete-computer) you should of course make sure
       that the account has "Delete computer object" permissions.

       If the computer object already exists the "Create computer object" permission does not apply anymore since now an existing object must be modified. Now
       permissions on the individual attributes are needed. e.g.  "Read and write Account Restrictions" or "Reset Password". For some attributes Active Directory has
       two types of permissions the plain "Read and Write" permissions and the "Validated Write" permissions. For the latter case there are two specific permissions
       relevant for adcli, namely

       ·   Validated write to DNS host name

       ·   Validated write to service principal name

       Details about the validation of the values can be found in the "Validated Writes" section of [MS-ADTS], especially dNSHostName[2] and servicePrincipalName[3]. To
       cut it short for "Validated write to DNS host name" the domain part of the fully-qualified hostname must either match the domain name of the domain you want to
       join to or must be listed in the msDS-AllowedDNSSuffixes attribute. And for "Validated write to service principal name" the hostname part of the service
       principal name must match the name stored in dNSHostName or some other attributes which are not handled by adcli. This also means that dNSHostName cannot be
       empty or only contain a short name if the service principal name should contain a fully-qualified name.

       To summarize, if you only have validated write permissions you should make sure the domain part of the hostname matches the domain you want to join or use the
       --host-fqdn with a matching name.
       The plain read write permissions do not run additional validations but the attribute values must still be in agreement with the general constraints mentioned
       above. If the computer object already exists adcli might need the following permissions which are also needed by Windows clients to modify existing attributes:

       ·   Reset Password

       ·   Read and write Account Restrictions

       ·   Read and (validated) write to DNS host name

       ·   Read and (validated) write to service principal name

       additionally adcli needs

       ·   Read and write msDS-supportedEncryptionTypes

       This is added for security reasons to avoid that Active Directory stores Kerberos keys with (potentially weaker) encryption types than the client supports since
       Active Directory is often configured to still support older (weaker) encryption types for compatibility reasons.

       All other attributes are only set or modified on demand, i.e. adcli must be called with an option the would set or modify the given attribute. In the following
       the attributes adcli can modify together with the required permissions are listed:

       ·   userPrincipalName

           ·   Read/Write userPrincipal Name

       ·   msDS-supportedEncryptionTypes

           ·   Read/Write msDS-SupportedEncryptionTypes

       ·   dNSHostName

           ·   Read/Write dNSHostName

           ·   Read and write DNS host name attributes

           ·   Validated write to DNS host name
     ·   servicePrincipalName

           ·   Read/Write servicePrincipalName

           ·   Validated write to service principal name

       ·   operatingSystem

           ·   Read/Write Operating System

       ·   operatingSystemVersion

           ·   Read/Write Operating System Version

       ·   operatingSystemServicePack

           ·   Read/Write operatingSystemServicePack

       ·   userAccountControl

           ·   Read/Write userAccountControl

       ·   description

           ·   Read/Write Description

       For the management of users and groups (adcli create-user, adcli delete-user, adcli create-group, adcli delete-group) the same applies only for different types
       of objects, i.e. users and groups. Since currently adcli only supports the creation and the removal of user and group objects it is sufficient to have the
       "Create/Delete User objects" and "Create/Delete Group objects" permissions.

       If you want to manage group members as well (adcli add-member, adcli remove-member) "Read/Write Members" permissions are needed as well.

       Depending on the version of Active Directory the "Delegation of Control Wizard" might offer some shortcuts for common task like e.g.

       ·   Create, delete and manage user accounts

       ·   Create, delete and manage groups

       ·   Modify the membership of a group
       The first 2 shortcuts will provided full access to user and group objects which, as explained above, is more than currently is needed. After using those shortcut
       it is a good idea to verify in the "Security" tab in the "Properties" of the related Active Directory container that the assigned permissions meet the
       expectations.

BUGS
       Please send bug reports to either the distribution bug tracker or the upstream bug tracker at
       https://bugs.freedesktop.org/enter_bug.cgi?product=realmd&component=adcli

SEE ALSO
       realmd(8), net(8), sssd(8)

       Further details available in the realmd online documentation at http://www.freedesktop.org/software/realmd/

NOTES
        1. Who can add workstation to the domain
           https://docs.microsoft.com/en-us/archive/blogs/dubaisec/who-can-add-workstation-to-the-domain

        2. dNSHostName
           https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/5c578b15-d619-408d-ba17-380714b89fd1

        3. servicePrincipalName
           https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/28ca4eca-0e0b-4666-9175-a37ccb8edada


</snip>

marking verified
Comment 9 errata-xmlrpc 2021-05-18 14:57:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (adcli bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1638