verbose/debug mode (unexpected pruning)

[pfulier]

Hello All,

please is there a way to make the manager (container) to log outputs with more verbosity than by default?

I am facing an issue, that one of the groups synced gets sometimes auto pruned, even the respective AD group is existing and contains users.
The log then says the sync was completely successful. The (unexpected) group pruning is indicated as well.
Next scheduled/forced run recreates the group again.

Could the issue be caused by situation, that the group is found on AD, but the transfer of data for the group from AD then fails (eg nw issue) and having no data for group received that means pruning of the group by the operator?

• Group Sync Operator - 0.0.24
• LDAP

Many thanks for your advices

Kind regards,

Peter

[pfulier]

Hello,

update.

I was able to reproduce the unexpected pruning issue in another environment, so it seems be common misbehavior...

That means, that with LDAP and prune set to true, one of the groups list whitelisted for syncing gets from time to time pruned from the (Openshift) cluster during sync execution.
As observed, the group impacted was the last group of the groups whitelisted.

Syncing is always successful, the group is indicated to be removed & removed in Prune group part log.
Next run recreates the group again.

Please does anybody face this issue as well / please can this be looked at?

Many thanks

Peter

[sveno1990]

We are experiencing the same issue for both LDAP providers as for Azure AD.
We notice it is happening on a regular interval, but it is ALWAYS the last group in alphabetical order that is pruned "wrongly". We notice it with group-sync instance that syncs 50 groups, but also once that only sync 1 group. We are currently running 0.25.

[sabre1041]

@sveno1990 @pfulier been attempting to replicate the issue without much success.

Would one of you be able to provide a detailed environment description as well as a GroupSync CR to attempt to replicate

[sveno1990]

Hi @sabre1041 thanks for looking into it. Below you can find the ldap config & AzureAD config we have the issue if we use both but also if we only use AzureAD.

LDAP

metadata:
  namespace: group-sync-operator
spec:
  providers:
    - ldap:
        ca:
          key: ca-bundle.crt
          kind: ConfigMap
          name: trusted-ca
          namespace: group-sync-operator
        credentialsSecret:
          kind: Secret
          name: ldap-provider-secret
          namespace: group-sync-operator
        prune: true
        rfc2307:
          usersQuery:
            baseDN: >-
              OU=<INSERT OUT>,OU=<INSERT OU>,OU=<INSERT OU>,DC=<INSERT DC>,DC=<INSERT DC>,DC=<INSERT DC>
            derefAliases: never
            scope: sub
          groupNameAttributes:
            - cn
          tolerateMemberNotFoundErrors: true
          tolerateMemberOutOfScopeErrors: true
          groupUIDAttribute: dn
          groupMembershipAttributes:
            - member
          userNameAttributes:
            - userPrincipalName
          groupsQuery:
            baseDN: >-
              OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,DC=<INSERT OU>,DC=<INSERT DC>,DC=<INSERT DC>
            derefAliases: never
            filter: (objectClass=group)
            scope: sub
          userUIDAttribute: dn
        url: 'ldaps://<INSERT FQDN>:636/'
        whitelist:
          - >-
            CN=<INSERT CN>,OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,OU=<INSERT OU>,DC=<INSERT DC>,DC=<INSERT DC>,DC=<INSERT DC>
      name: ldap
  schedule: 0 * * * *

AzureAD

kind: GroupSync
metadata:
  name: azure-groupsync
  namespace: group-sync-operator
spec:
  providers:
    - azure:
        credentialsSecret:
          kind: Secret
          name: azure-group-sync
          namespace: group-sync-operator
        filter: 'startswith(displayName,''<INSERT PREFIX>'')'
        prune: true
      name: azure
  schedule: 0 * * * *