microsoft.ad.group module fails to add member to existing group

[sigveo]

SUMMARY

When trying to add a computer to an existing Active Directory group, the play fails with error "New-ADGroup failed: The specified group already exists"

ISSUE TYPE

• Bug Report

COMPONENT NAME

microsoft.ad.group module

ANSIBLE VERSION

COLLECTION VERSION

CONFIGURATION

OS / ENVIRONMENT

Windows server 2025

STEPS TO REPRODUCE

- name: Define name of computer to be added to group
  ansible.builtin.set_fact:
    group_member: "{{ ansible_netbios_name }}$"

- name: Add computer to group in AD
  microsoft.ad.group:
    name: "{{ existing_group_name }}"
    scope: global
    members:
      add:
        - "{{ group_member }}"
    domain_username: "{{ domain_username }}"
    domain_password: "{{ domain_user_password }}"
  delegate_to: "{{ management_server_with_ActiveDirectory_module }}"

EXPECTED RESULTS

The computer to be added to the active directory group while preserving existing members

ACTUAL RESULTS

Fails with error "New-ADGroup failed: The specified group already exists"

[jborean93]

Please keep in mind that name is not the sAMAccountName of a group but rather the LDAP cn of the group in a path specified. The docs of microsoft.ad.group name state

The name of the AD object to manage, this is not the sAMAccountName of the object but the LDAP cn or name entry of the object in the path specified. Use identity to select an object to manage by its sAMAccountName.

If you are trying to add a member to a group that already exists but don't know the LDAP path the group is part of, use the identity parameter instead as that will lookup the group by sAMAccountName instead.

[Yannik]

@jborean93 I actually just ran into a very similar/identical issue.

Execute the following task twice:

    - microsoft.ad.group:
        name: mygroup@example.net
        path: "cn=Users,dc=example,dc=net"
        scope: global

...and the second task execution will fail with the error mentioned by OP:

TASK [microsoft.ad.group] ******************************************************************************************************************************************
fatal: [dc1]: FAILED! => changed=false 
  distinguished_name: null
  msg: 'New-ADGroup failed: The specified group already exists'
  object_guid: null

This shall not fail because the identity should be automatically constructed from name and path according to the docs:

If omitted, the AD object to manage is selected by the distinguishedName using the format CN={{ name }},{{ path }}. If path is not defined, the defaultNamingContext is used instead.

Further testing shows that this error occurs even when explicitly setting identity to the groups DN.

I believe this might an issue with the @-symbol, since this issue does NOT occur for a name of just mygroup instead of mygroup@example.net.

(In OPs case no path is given and we do not know if the object is in defaultNamingContext or elsewhere - neither do we know about the actual name of the group - feel free to elaborate on that @sigveo).

[Yannik]

...this occurs on microsoft.ad 1.9.1 (latest version).

[Yannik]

I believe what's happening is the following:

If identity is not set, it is constructed using CN={{ name }},{{ path }} (path=defaultNamingContext if not defined) as described above.
Relevant LOC: https://github.com/ansible-collections/microsoft.ad/blob/main/plugins/module_utils/_ADObject.psm1#L1104-L1113

Then, in Get-AnsibleADObject, if this identity matches regex ^.*\@.*\..*$, it uses a LDAPFilter (userPrincipalName=$($Matches[0])) for the Get-ADObject call: https://github.com/ansible-collections/microsoft.ad/blob/main/plugins/module_utils/_ADObject.psm1#L715

This regex is extremely broad and matches anything that contains a @ symbol and a "." some place later in the string.
Including the identity that was constructed earlier, which is infact a DN and not a emailadress/UPN.

Specifically, in my example above the LDAPFilter looks like this: (userPrincipalName=mygroup@example.net,cn=Users,dc=example,dc=net).

This is obviously does not return any matches.

Furthermore, the group objectClass does not even have a userPrincipalName attribute.

To fix this, I'd suggest:

• not ever filtering on userPrincipalName on objects that do not have that attribute (e.g. groups)
• only filter on userPrincipalName if the identity is actually a valid email-adress (and not a DN or just a samAccountName that happens to include a @ and "." char)

[sigveo]

My problem is that the task actually finds the group, (so the format of the group name is actually not relevant here), but instead of modifying the group, it tries to create the group.

So in my use case, I have resorted to using shell instead and use "Add-ADGoupMember" instead of "New-ADGroup", which this module seems to use.

This works, (but reports "Changed" every time):
ansible.windows.win_shell: Add-ADGroupMember -Identity "{{ existing_group_name }}" -Members "{{ group_member }}"

So is there a way for the module to use Add-ADGroupMember when modifying the members of a group?

[Yannik]

@sigveo Okay, since these are two separate problems, I have created a new issue (#198) and hidden my comments as off-topic.