Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1854112

Summary:	[RFE] Add new mode to just create an AD account to be able to connect to LDAP
Product:	Red Hat Enterprise Linux 8	Reporter:	Sumit Bose <sbose>
Component:	adcli	Assignee:	Sumit Bose <sbose>
Status:	CLOSED ERRATA	QA Contact:	shridhar <sgadekar>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	8.3	CC:	abokovoy, dlavu, sgadekar, sgoveas
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.0	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sync-to-jira qetodo
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 Sumit Bose 2020-07-06 12:38:23 UTC

Description of problem:

By default the typical way to get credentials to allow a host to access resources in Active Directory is to join the domain. For this a host account with a given set of attributes is created. If other domains trust those credentials they can be used to access resources on those domains as well.

If there is no trust between two different domains or there is only a one-way pointing in the wrong direction or the second domain is in a different forest and SSSD is used, it would be good to have a second set of credentials so that the resources of the second domain can be accessed as well.

Just calling 'adcli join' for the second domain as well might cause issues because there are a number of constraints to respect. E.g. the client name, Kerberos user and service principals etc should be unique to avoid various kinds of issue.

To solve this a new mode, e.g. 'adcli ldap_account' which creates just a minimal "service account" with a unique name would be useful.

Comment 4 Sumit Bose 2020-10-21 18:57:22 UTC

Hi Alexander,

do you think a msDS-ManagedServiceAccount object like e.g.

dn: CN=myhost_srv4234,CN=Managed Service Accounts,DC=ad,DC=devel
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
objectClass: computer
objectClass: msDS-ManagedServiceAccount
cn: myhost_srv4234
description: Please do not edit, Service account for myhost.ad.devel, managed 
 by adcli.
distinguishedName: CN=myhost_srv4234,CN=Managed Service Accounts,DC=ad,DC=deve
 l
instanceType: 4
whenCreated: 20201021151302.0Z
whenChanged: 20201021152618.0Z
uSNCreated: 2956166
uSNChanged: 2956186
name: myhost_srv4234
objectGUID:: cWSkhDIO4UGvmSwoidz9fw==
userAccountControl: 69632
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 132477667827500000
lastLogoff: 0
lastLogon: 132477669590625000
localPolicyFlags: 0
pwdLastSet: 132477667827031250
primaryGroupID: 515
objectSid:: AQUAAAAAAAUVAAAA+BIT3EfzHHZHLy7X6acAAA==
accountExpires: 9223372036854775807
logonCount: 2
sAMAccountName: myhost_srv4234$
sAMAccountType: 805306369
objectCategory: CN=ms-DS-Managed-Service-Account,CN=Schema,CN=Configuration,DC
 =ad,DC=devel
isCriticalSystemObject: FALSE
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 132477667827656250
msDS-SupportedEncryptionTypes: 28


is suitable for this service account? The '_srv4234' part is a random component of the name so that it unique in the forest. Or would a plain user object be better so that only authentication is possible and no one gets the idea to add SPNs to the object?

bye,
Sumit

Comment 5 Alexander Bokovoy 2020-10-22 06:56:58 UTC

Here are our options (taken from https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts#BKMK_Intro):

  Principals                                     | Scope   | Services supported                           | Password management
-----------------------------------------------------------------------------------------------------------------------------
A Computer Account of Windows system             | Domain  | Limited to one domain joined server          | Computer manages
B Computer Account without Windows system        | Domain  | Any domain joined server                     | None
C Virtual Account                                | Local   | Limited to one server                        | Computer manages
D Windows 7 standalone Managed Service Account   | Domain  | Limited to one domain joined server          | Computer manages
E User Account                                   | Domain  | Any domain joined server                     | None
F Group Managed Service Account                  | Domain  | Any Windows Server 2012 domain-joined server | The domain controller manages, and the host retrieves

Currently we support only (A) and the proposal is to add support of (D), or perhaps (E).

(D) was added in Windows Server 2008 R2. It means any deployment that still using Windows Server 2003 schema (e.g. old forest root domains, for example) would not be able to use this technique (or any other than (A) and (B)). I guess this is practical limitation: Windows Server 2003 is already out of support. (E) would work for Windows Server 2003 as well.

The main benefit of (D) over (E) is to avoid applying domain- and fine-grained password policies as those do not make sense for computer objects with cryptographically strong generated passwords. So I would see (D) as a preferred option.

Comment 6 Sumit Bose 2020-10-27 17:34:47 UTC

Hi,

thanks for the comment. I continued to use a Managed Service Account and tried to describe the new sub-command in the following man page section. Please let me know if you have any comments or suggestions:

CREATE A SERVICE ACCOUNT
adcli service-account creates a managed service account in the given
Active Directory domain. This is useful if a computer should not fully
join the domain but LDAP access is needed. A typical use case is that
the computer is already joined an Active Directory domain and needs
access to another domain in the same or a trusted forest where the host
credentials from the joined domain are not valid, e.g. there is only a
one-way trust.

$ adcli service-account --domain=domain.example.com
Password for Administrator:

The main difference between the service account and the account of a
domain member are the missing service principals. All kerberized
services a host provides should added to the host object.

Since it is expected that a client will most probably join to its DNS
domain the service account will be needed for a different domain and as
a result the domain name is a mandatory option. If called with no other
options adcli service-account will use the short hostname with an
additional random prefix as computer name to avoid name collisions.
Since there is a historical limit of 16 character of NetBIOS names
including a trailing '$' but the related LDAP attribute sAMAccountName
has a limit of 20 characters the prefix consists of a '!' as separator
and 3 random characters from number and upper- and lowercase ASCII
characters. E.g. for a host with the short name 'myhost' will have a
common name 'myhost!A2c' and a sAMAccountName/NetBIOS name
'myhost!A2c$' and a Kerberos principal
'myhost!A2c$@DOMAIN.EXAMPLE.COM'.

The Kerberos keys are written locally into a keytab file which is the
default keytab file, typically /etc/krb5.keytab, with the domain name
in lower-case as a prefix, e.g. /etc/krb5.keytad.domain.example.com.

adcli service-account can be called multiple times to reset the
password of the service account. To identify the right account with the
random component in the name the corresponding principal is read from
the keytab. If the keytab got deleted adcli will try to identify an
existing service account with the help of the fully-qualified name, if
this fails a new service account will be created.

The service account password can be updated with

$ adcli update --domain=domain.example.com --host-keytab=/etc/krb5.keytad.domain.example.com

and the service account can be deleted with

$ adcli delete-computer --domain=domain.example.com 'myhost!A2c'

In addition to the global options, you can specify the following
options to control how this operation is done.

-N, --computer-name=computer
The short non-dotted name of the service account that will be
created in the domain. The long option name --computer-name is kept
to underline the similarity with the same option of the other
sub-commands. If not specified, then the first portion of the
--host-fqdn or its default is used with a random suffix.

-O, --domain-ou=OU=xxx
The full distinguished name of the OU in which to create the
service account. If not specified, then the service account will be
created in a default location.

-H, --host-fqdn=host
Override the local machine's fully qualified domain name. If not
specified, the local machine's hostname will be retrieved via
gethostname(). If gethostname() only returns a short name
getaddrinfo() with the AI_CANONNAME hint is called to expand the
name to a fully qualified domain name.

-K, --host-keytab=/path/to/keytab
Specify the path to the host keytab where host credentials will be
written after a successful join operation. If not specified, the
default location will be used, usually /etc/krb5.keytab with the
lower-cased domain name added as a prefix e.g.
/etc/krb5.keytab.domain.example.com.

--show-details
After a successful join print out information about join operation.
This is output in a format that should be both human and machine
readable.

--show-password
After a successful join print out the service account password.
This is output in a format that should be both human and machine
readable.

Thanks.

bye,
Sumit

Comment 12 Sumit Bose 2020-11-12 17:12:27 UTC

Upstream:
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/4e4dbf8d2b437808863f8be85e7f30865d88c7fc
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/41379f7ad6a9442dd55cc43d832427911e86db31
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/eea6a8071b5e5df74808903bb15b30acf820ce3f
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/2750f536ac6746756335eec8332060d2365a4126
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/81c98e367ba4bc8d77668acd31e462ad31cf12be
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/2a695dfe09cafeee3a648d3b969c364f8d3f494f
 - https://gitlab.freedesktop.org/realmd/adcli/-/commit/6b94f9712378b8f1fa1bc530c64cb987abb0c43b

Comment 16 shridhar 2020-12-08 20:43:54 UTC

Tested with following data:

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   TEST PROTOCOL
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

    Test run ID   : 7776001
    Package       : adcli
    Installed     : adcli-0.8.2-8.el8.x86_64
    beakerlib RPM : beakerlib-1.20-1.el8bkr.noarch
    bl-redhat RPM : beakerlib-redhat-1-30.el8.noarch
    Test name     : /CoreOS/adcli/Regression/bz1854112-RFE-new-mode-to-create-AD-account-to-connect-LDAP
    Test version  : 1.0
    Test started  : 2020-12-08 15:35:58 EST
    Test finished : 2020-12-08 15:36:58 EST (still running)
    Test duration : 60 seconds
    Distro        : Red Hat Enterprise Linux release 8.4 Beta (Ootpa)
    Hostname      : ci-vm-10-0-139-212.hosted.upshift.rdu2.redhat.com
    Architecture  : x86_64
    CPUs          : 1 x Intel Xeon Processor (Skylake, IBRS)
    RAM size      : 1816 MB
    HDD size      : 19.98 GB


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a  Managed Service Account
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:09 ] :: [  BEGIN   ] :: Running 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --verbose --stdin-password'
 * Using service account keytab: FILE:/etc/krb5.keytab.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Calculated domain realm from name: AD.BASEOS.QE
 * Discovering domain controllers: _ldap._tcp.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-fMSq4a/krb5.d/adcli-krb5-conf-xJmwJ5
 * Authenticated as user: Administrator.QE
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: AD
 * Looked up domain SID: S-1-5-21-3917357665-4280980005-1639201238
 * Using fully qualified name: ci-vm-10-0-139-.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: CI-VM-10-0-139-
 * Using domain realm: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Generated 120 character computer password
 * Using keytab: FILE:/etc/krb5.keytab.ad.baseos.qe
 * A service account for CI-VM-10-0-139-$ does not exist
 * A service account for ci-vm-10-0-139-.ad.baseos.qe does not exist
 * Found well known service container at: CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Calculated service account: CN=CI-VM-10-0-139-!S3A,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Encryption type [16] not permitted.
 * Encryption type [23] not permitted.
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created service account: CN=CI-VM-10-0-139-!S3A,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Set service password
 * Retrieved kvno '2' for service account in directory: CN=CI-VM-10-0-139-!S3A,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Discovered which keytab salt to use
 * Added the entries to the keytab: CI-VM-10-0-139-!S3A$@AD.BASEOS.QE: FILE:/etc/krb5.keytab.ad.baseos.qe
:: [ 15:36:16 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:16 ] :: [  BEGIN   ] :: Running 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!s3a --verbose --stdin-password'
 * Calculated domain name from host fqdn: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Calculated domain realm from name: AD.BASEOS.QE
 * Discovering domain controllers: _ldap._tcp.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-1pIIAn/krb5.d/adcli-krb5-conf-iMr73E
 * Authenticated as user: Administrator.QE
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: AD
 * Looked up domain SID: S-1-5-21-3917357665-4280980005-1639201238
 * Using fully qualified name: ci-vm-10-0-139-.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: CI-VM-10-0-139-
 * Using domain realm: ad.baseos.qe
 * Not setting fully qualified name
 * Enrolling computer name: ci-vm-10-0-139-!s3a
 * Found service account for ci-vm-10-0-139-!s3a$ at: CN=CI-VM-10-0-139-!S3A,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Deleted service account at: CN=CI-VM-10-0-139-!S3A,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
:: [ 15:36:20 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!s3a --verbose --stdin-password' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 11s
::   Assertions: 2 good, 0 bad
::   RESULT: PASS (Create and delete a  Managed Service Account)


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a  Managed Service Account with a custom location of keytab
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:20 ] :: [  BEGIN   ] :: Running 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --host-keytab=/etc/krb5.keytab.different --verbose --stdin-password'
 * Using service account keytab: /etc/krb5.keytab.different
 * Using domain name: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Calculated domain realm from name: AD.BASEOS.QE
 * Discovering domain controllers: _ldap._tcp.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-SCVy2u/krb5.d/adcli-krb5-conf-Uz406X
 * Authenticated as user: Administrator.QE
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: AD
 * Looked up domain SID: S-1-5-21-3917357665-4280980005-1639201238
 * Using fully qualified name: ci-vm-10-0-139-.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: CI-VM-10-0-139-
 * Using domain realm: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Generated 120 character computer password
 * Using keytab: /etc/krb5.keytab.different
 * A service account for CI-VM-10-0-139-$ does not exist
 * A service account for ci-vm-10-0-139-.ad.baseos.qe does not exist
 * Found well known service container at: CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Calculated service account: CN=CI-VM-10-0-139-!9hY,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Encryption type [16] not permitted.
 * Encryption type [23] not permitted.
 * Encryption type [3] not permitted.
 * Encryption type [1] not permitted.
 * Created service account: CN=CI-VM-10-0-139-!9hY,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Set service password
 * Retrieved kvno '2' for service account in directory: CN=CI-VM-10-0-139-!9hY,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Discovered which keytab salt to use
 * Added the entries to the keytab: CI-VM-10-0-139-!9hY$@AD.BASEOS.QE: /etc/krb5.keytab.different
:: [ 15:36:28 ] :: [   PASS   ] :: Command 'echo -n weareawesome2012! | adcli create-msa --domain=ad.baseos.qe --host-keytab=/etc/krb5.keytab.different --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:28 ] :: [  BEGIN   ] :: Running 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!9hy --verbose --stdin-password'
 * Calculated domain name from host fqdn: ad.baseos.qe
 * Calculated computer account name from fqdn: CI-VM-10-0-139-
 * Calculated domain realm from name: AD.BASEOS.QE
 * Discovering domain controllers: _ldap._tcp.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Sending NetLogon ping to domain controller: sec-ad1.ad.baseos.qe
 * Received NetLogon info from: sec-ad1.ad.baseos.qe
 * Wrote out krb5.conf snippet to /tmp/adcli-krb5-E0aIJc/krb5.d/adcli-krb5-conf-EjtVD1
 * Authenticated as user: Administrator.QE
 * Using GSS-SPNEGO for SASL bind
 * Looked up short domain name: AD
 * Looked up domain SID: S-1-5-21-3917357665-4280980005-1639201238
 * Using fully qualified name: ci-vm-10-0-139-.ad.baseos.qe
 * Using domain name: ad.baseos.qe
 * Using computer account name: CI-VM-10-0-139-
 * Using domain realm: ad.baseos.qe
 * Not setting fully qualified name
 * Enrolling computer name: ci-vm-10-0-139-!9hy
 * Found service account for ci-vm-10-0-139-!9hy$ at: CN=CI-VM-10-0-139-!9hY,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
 * Deleted service account at: CN=CI-VM-10-0-139-!9hY,CN=Managed Service Accounts,DC=ad,DC=baseos,DC=qe
:: [ 15:36:32 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!9hy --verbose --stdin-password' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 12s
::   Assertions: 2 good, 0 bad
::   RESULT: PASS (Create and delete a  Managed Service Account with a custom location of keytab)



[....]


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a  Managed Service Account
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:16 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:20 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!s3a --verbose --stdin-password' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 11s
::   Assertions: 2 good, 0 bad
::   RESULT: PASS (Create and delete a  Managed Service Account)


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a  Managed Service Account with a custom location of keytab
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:28 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --host-keytab=/etc/krb5.keytab.different --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:32 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!9hy --verbose --stdin-password' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 12s
::   Assertions: 2 good, 0 bad
::   RESULT: PASS (Create and delete a  Managed Service Account with a custom location of keytab)


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a  Managed Service Account with a custom OU
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:39 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli create-msa --domain=ad.baseos.qe --domain-ou=CN=Computers,dc=ad,dc=baseos,dc=qe --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:43 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!s3a --verbose --stdin-password' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 11s
::   Assertions: 2 good, 0 bad
::   RESULT: PASS (Create and delete a  Managed Service Account with a custom OU)


::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Create and delete a Managed Service Account over LDAPS
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

:: [ 15:36:43 ] :: [   LOG    ] :: Add rule for dropping port TCP 389
:: [ 15:36:43 ] :: [   PASS   ] :: Command 'iptables -A OUTPUT -p tcp --destination-port 389 -j DROP' (Expected 0, got 0)
:: [ 15:36:43 ] :: [   PASS   ] :: Command 'iptables-save' (Expected 0, got 0)
:: [ 15:36:51 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli create-msa --use-ldaps --domain=ad.baseos.qe --verbose --stdin-password ' (Expected 0, got 0)
:: [ 15:36:56 ] :: [   PASS   ] :: Command 'echo -n sec! | adcli delete-computer ci-vm-10-0-139-!s3a --use-ldaps --verbose --stdin-password' (Expected 0, got 0)
:: [ 15:36:56 ] :: [   PASS   ] :: Command 'iptables -D OUTPUT -p tcp --destination-port 389 -j DROP' (Expected 0, got 0)
:: [ 15:36:56 ] :: [   PASS   ] :: Command 'iptables-save' (Expected 0, got 0)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::   Duration: 13s
::   Assertions: 6 good, 0 bad
::   RESULT: PASS (Create and delete a Managed Service Account over LDAPS)


marking verified.

Comment 18 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