0

Is there a way to get the Group the User is member of so we can process the authentication, or even throw exception so the token will not be created.

The reason we need groups is that we can not create OU in Azure AD whereas we could before in LDAP. We retrieved the distinguished name and therefore had very rich information about said user.

Lastly, we do see that you could create an OU on-premises but read that Graph API would not recognize it or could not retrieve it.

We are attempting to do logic within the SecurityTokenValidated stage of Authentication process and we break the process whenever we try to use:

string UPN = context.AuthenticationTicket.Identity.FindFirst(ClaimTypes.Name).Value

Is this because we are using MSAL?

twc
  • 449
  • 1
  • 3
  • 12
  • I see that you have tagged the question [microsoftgraph]. Have you looked at the Microsoft Graph? What have you tried? What worked, and what didn't work? – Philippe Signoret Mar 14 '17 at 23:02
  • Sure I'm using Microsoft Graph API to do many things, mail, calendar, etc - but, we need some segregation that the OU provides in the Active Directory and as we stated we can create and OU but can't retrieve it using Microsoft Graph so it renders that useless - as we read. Directly answering your question, we have not attempted to get the groups the user is member of during the authentication process because we wanted to know if there was some other way to get a distinct user group at the authentication process. – twc Mar 14 '17 at 23:18
  • Also, how would you make the query with the user in question when that query has to be performed with admin status? Thank you for your time, Tim: – twc Mar 14 '17 at 23:30
  • `memberOf` for the signed-in user does not need admin permissions (only admin consent to the application). I'll provide a full answer in a few minutes. – Philippe Signoret Mar 14 '17 at 23:35

1 Answers1

2

The best approach for you to take here is to make use of the group claims capability of Azure AD. (And for get OUs. OUs are not represented in Azure AD at all.)

Dushyant Gill's blog post on this is relatively old, but still very much relevant: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/. In short, the process is:

  1. Enable group claims for your application by setting the groupMembershipClaims property in your application. After setting this, when a user signs in to your application, the list of groups they are a member of will be included in the token (if the number of groups is smaller than the limit).
  2. Update your application's authorization code to make use of the group membership claims (if present).
  3. Update your application to query the Azure AD Graph API if the groups membership claim is not present (i.e. if the "overage" claim is present). This happens only when the user is a member of more than 150-250 groups. (Use the _claim_name and _claim_sources claims as indications that the Graph API needs to be called directly.)

As described in the documentation for Azure AD Graph API permissions, in order for your application to call the getMemberGroups method, the app must have the "Read all groups" permission (Groups.Read.All). This permission requires admin consent, but once consent has been granted, the request can be made using the signed-in user's access token.

Philippe Signoret
  • 13,299
  • 1
  • 40
  • 58
  • Can we make a distinction within the Groups --- such as "Primary"? – twc Mar 15 '17 at 10:44
  • I'm starting to see this is more of a global problem --- http://stackoverflow.com/questions/42747115/unique-user-id-in-multi-tenant-azure-ad-apps whereas the x.500 standards like CN and OU are not in the Azure Directory. I only add this as so maybe we can come up with a concrete solution. – twc Mar 15 '17 at 10:50
  • http://stackoverflow.com/questions/35878421/azure-ad-retrieve-a-on-prem-ad-group-common-name - here it is again yet no real solution. – twc Mar 15 '17 at 10:52
  • In general, my recommendation would be to avoid defaulting to existing paradigms and patterns from the on-premises world. I didn't quite catch how this is related to the link from your second comment. In the link from your third comment, the OP is simply asking for something tat does not exist. – Philippe Signoret Mar 16 '17 at 07:40
  • LDAP is the basis for Active Directory which has been around a long time as a standard and still is a standard. Nevertheless, as you can see from my comment, can we make a group unique? – twc Mar 16 '17 at 13:03
  • Currently, we are using MSAL (preview) --- we can use ADAL, but wanted to check to see if we are doing this correctly as we break the process with doing logic inside the SecurityTokenValidated process of authentication. whereas it does not break the process using ADAL. Thank you, Tim: – twc Mar 16 '17 at 13:06
  • Azure AD does not support LDAP (though you can enable Azure AD Domain Services, if you have an app with legacy code). I don't quite understand "can we make a group unique". The object IDs for each group is a unique, immutable value. – Philippe Signoret Mar 16 '17 at 19:32
  • Unique or I should say Default parameter - like SMTP for proxyaddresses the capitalization indicates a Uniqueness among all smtp addresses. – twc Mar 17 '17 at 12:07
  • Azure does not support X.500 in which LDAP is used to query is more accurate, just in case others read this. Maybe I can be corrected on this next statement, Graph is to Azure AD like LDAP is to X.500 Directory. – twc Mar 17 '17 at 12:11