6:17 a.m.
On to, 19 tammi 2023, John Smith via FreeIPA-users wrote:
@Alex, I already solved an issue. Everything is OK with freeipa,
problem was in Azure and my user. I discovered that I didn't provide
you a full logtrace, look:
[skip]
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: User
Principal: [(null)].
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: User oid: [(null)].
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: User sub:
[KMO6l3C0F39e2ZO28BcGo7Aqx3kT1JCrDwh287mXWqU].
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: userinfo: [{"sub":
"KMO6l3C0F39e2ZO28BcGo7Aqx3kT1JCrDwh287mXWqU", "name": "Sebastian
XXXXX", "family_name": "XXXXX", "given_name":
"Sebastian", "picture":
"https://graph.microsoft.com/v1.0/me/photo/$value"}].
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: Failed to read attribute [email]
from userinfo data.
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: No attribute to identify the user
found.
Jan 19 12:43:55 server.ipademo.local oidc_child[10327]: Failed to get user identifier.
Yeah, this should be your clear indicator. Perhaps, we should add a bit
of explanation in the documentation that certain scopes require
additional information and it would be great to check a presence of that
information during troubleshooting.
as I discovered I didn't provide in my user email attribute in
Azure
AD, which seems to be odd for me as it is not an required field,but
once I provided it in Azure eeverything started working again. So that
very important step in whole process of configuration.
In the security section of
https://freeipa.readthedocs.io/en/latest/designs/external-idp/idp-api.htm... we
say:
----
Kerberos pre-authentication method idp relies on the user subject
(ipaIdpSub LDAP attribute) defined in the LDAP object entry to match the
Kerberos principal and the OAuth 2.0 resource owner. When openid OAuth
2.0 scope is used, this typically maps to sub value. Since there are no
ways to pull this value for all users in advance, pre-populated IdP
templates set OAuth 2.0 scopes to include email and then use email to
map IdP subject where possible. There are some well-known IdPs which
allow reuse of user accounts and emails, this applies to both Github and
Gitlab. Since Gitlab does not support OAuth 2.0 Device authorization
grant flow, it is not an issue in itself for this project. However, for
Github it is known that user accounts can be recycled after their
removal. In this case we would recommend to use internal Github
identifier instead.
----
Unfortunately, there is no an easy way for third-party applications to
obtain userinfo's "sub" part automatically without asking for a user
authorization, so we cannot retrieve that automatically and populate
user entries. It is a bit of a pain to admins; if somebody has any idea
how we can achieve that using the same OAuth2.0 client ID and get it
working for all OAuth 2.0 IdPs, please tell us.
I was confused by the oidc_behaviour which runs whole flow again with
new Device code and then gives us HTTP/1.1 400 Bad Request, I didn't
check the prvious logs as I thought that was the start of the request,
then I look on timestamps and I realized there is much more before this
second attempt.
So it looks like flow was that
1 prompt with device ID
2. authorization with my azure ad account
3. get an error from azure as lack of email attribute in userinfo
4. another posts are made with diffrent device id which are not prompted in commandline
5 error 400 bad request from the 4 not from 3 step
Thank you all for your help. For now this case for me solved, right now
I will get another deep dive to configure other stuff.
Great that it works for you!
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland