can't auth by azure

[dgsfor]

I configure it through this document: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/microsoft/#azure-ad-saml-enterprise-app-auth-using-dex

but,I got some error in pod (argocd-dex-server):

{"level":"error","msg":"Failed to authenticate: no attribute with name "email": [http://schemas.microsoft.com/identity/claims/tenantid http://schemas.microsoft.com/identity/claims/objectidentifier http://schemas.microsoft.com/identity/claims/identityprovider http://schemas.microsoft.com/claims/authnmethodsreferences http://schemas.microsoft.com/ws/2008/06/identity/claims/wids Group]","time":"2022-09-09T03:34:47Z"}

Please help me！

[dgsfor]

there is some config in azure:

[dgsfor]

I solved this problem by set the self account email addr in azure console.

[galingit]

Hi there! We are getting the same error message. We also followed the same guide. Adding email to users account does not solved the issue. We are in enterprise scenario setup that all user attributes are managed via local metaTree tool that is synced with AzureAD. All users that we added to ArgoCD Groups have email attribute in Azure AD accounts. Please, advice how to troubleshoot this issue. Thank you in advance!

[woehrl01]

@galingit @gsgs-libin

If you don't have the user.mail field setup in Azure, you have to map a different field in the Attributes & Claim section, possible fields could be user.userprincipalname which often contains a mail address, too.

[galingit]

@woehrl01 Thanks for the reply! We have tried with both suggestions, but still the same result. Here is the screenshot from our Azure SP configuration:

We also tried as you suggested:

We always get this message when user try to login via SAML:

[woehrl01]

I just had a look at my config, we are not using dex, and we are using OIDC instead of SAML. Have you tried that, too?

[galingit]

@woehrl01 We would try this. Can you share your oidc.config please? Thank you in advance

[woehrl01]

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  admin.enabled: "false"

  oidc.config: |
    name: Azure
    issuer: https://login.microsoftonline.com/xxxxx-xxxxxx-xxxxxxx-xxxxx/v2.0
    clientID: $argo-sso-creds:clientId
    clientSecret: $argo-sso-creds:apiKey
    requestedIDTokenClaims:
        groups:
            essential: true
    requestedScopes:
        - openid
        - profile
        - email

Sure, this is our configuration. admin.enabled: false can be used to remove the login form and use SSO only.

Azure AD itself is configured as described here: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/microsoft/#azure-ad-app-registration-auth-using-oidc

[galingit]

@woehrl01 We tested with OIDC config and it successfully perform login to azure, but then it says that certificate is bad:

We using wildcard certificate for our enterprise domains. It is issued by internal CA.

[galingit]

I was able to make it working with SAML at the end by disabling ArgoCD <-> DEX TLS communication, but this should not be a problem as we will have service mesh to handle mTLS for our micro-services running on AKS. @woehrl01 thanks for the help!! much appreciate :)

[ixolt]

@gsgs-libin I just found that the long list of groups is weakside of DEX, in my case, filtering helped

[g-bohncke]

This issue is also described in https://github.com/dexidp/dex/issues/1309

Looks to be a config/documentation issue, this is given in the documentation:

• usernameAttr: email
• emailAttr: email
• groupsAttr: Group

But configuring it as:

• usernameAttr: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
• emailAttr: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
• groupsAttr: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

makes it work.

[harikishore23]

This issue is also described in dexidp/dex#1309

Looks to be a config/documentation issue, this is given in the documentation:

• usernameAttr: email
• emailAttr: email
• groupsAttr: Group

But configuring it as:

• usernameAttr: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
• emailAttr: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email
• groupsAttr: http://schemas.microsoft.com/ws/2008/06/identity/claims/groups

makes it work.

This solution worked for me.