Open dgsfor opened 2 years ago
there is some config in azure:
I solved this problem by set the self account email addr in azure console.
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!
@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.
@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:
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?
@woehrl01 We would try this. Can you share your oidc.config please? Thank you in advance
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
@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.
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 :)
@gsgs-libin I just found that the long list of groups is weakside of DEX, in my case, filtering helped
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:
But configuring it as:
makes it work.
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.
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!