I've been evaluating Azure Active Directory B2C as a solution for an identity provider I need for an upcoming project.
During my evaluation I noticed the following behavior that I am not sure should be possible:
I am in my B2C tenant and I invite a new guest user. In this case it is for a different email address that I control. This email address has no association to this B2C instance nor the parent AD instance, the Azure account or anything related. It is a throw away account I am using for testing.
I get the invitation sent to that address and log in through a different browser in incognito mode. I create my account and complete that flow.
Now here is where I am slightly concerned with security:
Logged in as this user I am able to do the following:
Log into the B2C instance and see some top level info such as the TenantId, etc...
I do not see other users BUT I can click on the "New Guest User" button ("New User" is greyed out) and can attempt to create/invite users. I am blocked from all the operations I tried but it seems strange to surface this UI.
Even though it said the operation was blocked my invitation to another email address I control actually went through. I was able to go through the invitation flow. There were some errors and it even said the invitation code was not valid... but despite this the invitation completed and I was able to log into the tenant management UI with this new user.
This user was also able to create invitations.
I also see this new user that was invited by the guest in my user list logged in as the account admin.
So my questions are:
Is this by design? Why?
Is this a possible bug?
Can this be blocked?
Why can B2C guest users invite other users and initiate the flow?
Why can B2C guest users even log into the tenant management site?
I can't imagine why a default scenario would allow new users that have not been given any privileges to view your tenant and invite other guests. In my scenario this should not be possible.
The idea of guest users in B2C is to invite other people who can be admins.
These people are not local users.
If you want to invite people to be local users, use a magic link.
We are looking to set up a solution to monitor primarily the Global Admin role in Azure AD, so if a user is added to or removed from the role an e-mail is sent to a specific mailbox.
On our local AD we have a working solution for this, but I can't seem to find a similar solution for AAD.
In the Office 365 Security & Compliance Center > Alerts > Alert Policies there is a policy called "Elevation of Exchange admin privilege" which basically does what I want, except it only targets the Exchange Admin role.
I've tried creating a new policy from scratch, but as far as I can tell there is no way to choose to target a specific role. There is only the "Granted Exchange admin permission" and nothing really comes up when I search for "role" or "admin" in the "Activity is" drop down.
I've also looked at the MCAS (MS Cloud App Security) policies but nothing there seems to be what I need either.
I found this article: Monitor Office 365 admin role changes in all customer tenants but it seems to be geared more towards multitenant environments and requires quite a bit och additional setup. I was hoping there was a simpler solution for a single tenant environment.
Kind regards
If you have MCAS, I think it's possible that you have PIM as well (privileged identity Management. it requires aad P2 skus. But assuming you do, then it's very simple to do this. You would just go into the PIM in azure, click azure ad roles, click manage roles, choose the global admin role, Click role settings, and you will see options like this
If you don't have PIM, then it becomes quite a bit more complicated but could probably be less complicated than your example, you could set up log analytics to ingest azure ad data, and using a query pull out that information (role assignment event for example), then you could set up an alert in monitor referencing a log analytics workspace. https://learn.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics
As you can see from the image, it's not letting regular users login to the application. How do I bring down this access to members? This is an azure active directory application. I can login just fine with an admin user but my regular accounts gets blocked. Note, I created the application with the regular account. I don't suppose this has something to do with it?
I've granted the app all delegated permissions. No application permissions though. I'm thinking there's something in the manifest I need to alter but I'm not sure and I've never messed with this before. So any help is appreciated.
You likely need to perform admin consent for the application. There are two ways to do this in Azure AD:
In the Azure portal, you can go into the App Registrations blade, then click on the App, click on Permissions, and hit Grant Permissions.
Construct a request to Azure AD with the extra parameter &prompt=admin_consent.
For example:
https://login.microsoftonline.com/common/oauth2/authorize?client_id=<AppID>&resource=<Resource App ID URI>&response_type=code&redirect_uri=<Redirect URI>&prompt=admin_consent
I have granted access to a couple of users with different roles against resource group on Azure portal. User whom I have granted access rights do not see the resource group when they login to azure portal.
Have I missed something while granting access rights?
You are probably in the wrong Azure directory. You can solve this issue with the following steps.
Login to the azure portal here: https://portal.azure.com/ with your
credentials
Click the top right icon which shows a generic person
icon and opens a drop down about your profile/account
Click 'Switch Directory' and switch into the directory of the
organization where you have been granted access.
Look over to the left. You should now see the resources that you
were granted access to under 'All Resources'
I encountered the same issue. Portal just needed refreshing. Just switched the user directories and came back to the user directory I had given access to, then I could see the resource group under that user.
Honestly, Azure really does make stuff a lot harder than need be sometimes. In my case I needed to go to portal settings (gear icon in top bar), click on the default subscription filter and enable all subscriptions.
After the Ad integration of the ektron site how to to go about preventing certain active directory users from logging in to the work area?
Quick and Simple answer:
Once you start enabling AD Authentication, it becomes all-or-nothing. You cannot mix user authentication modes.
CMS and Membership users can auth against Ektron.
CMS users can auth against AD and Membership can auth against Ektron.
CMS and Membership can auth against AD.
You cannot mix.
If everyone is a CMS users, but not everyone should be doing "stuff" in the Workarea, you need to start managing User Groups and set permissions to restrict or allow activity in Workarea based on those groups. First thing: Deny everything to the Everyone group. Then start allowing activity to other groups.
The Complex and Long explanation of user management in Ektron:
With AD Authentication and Integration options in Ektron, you have a couple ways to manage user authentication, and how users exist in the system.
Standard AD Authentication - When enabled through the Web.config with ek_ADEnabled, and then through the Workarea > Settings > Configuration > Active Directory > Setup > "Enable Active Directory Authentication", AD users that login to the system will be handled as CMS users. Explanation about this: Just checking the radio button here and leaving the checkboxes unchecked will force CMS authentication against AD. This does not auto-add authenticated users, update properties, or force them into groups. It simply tests their username and pass against an LDAP query. Using just this method, you manually add the users you want to authenticate for CMS/Workarea access into the Users. Any users that are not added, will not be authenticated. Any other users would then use a membership username and pass to authenticate on the site and will not use AD.
Active Directory Itegration - Using the above method, you can enable "Integration." This updates the users properties and information from Active Directory when they log in successfully. With "Authentication" the user information, aside from UserName, Domain, and password, is managed in Ektron whereas "Integration" forces the rest of the user properties to match their AD values. Just enabling "Integration" still forces the users to be added manually to Users and any AD users who do not exists in Users cannot authenticate. Instead, they would need a non-ad Ektron Membership account to login.
Auto Add Options - With "Integration" enabled, you can enable the auto-creation of users in Ektron. If a user logs in to Ektron and successfully authenticates against Active Directory, but does not exist in Ektron yet, the user account will be created in Ektron in the Everyone group and will be granted those permissions. This means that all Active Directory users on your domain can authenticate as CMS users and get access. Enabling the "Auto Add User to Group" takes this an additional step and checks their AD User Groups against the Ektron groups. If one of the Ektron groups matches an AD group they are in, they will be added to the group in Ektron.
AD Memberships - If you only want a couple users in your Active Directory tree to have CMS access, and want the rest of your users to log in to the site using Active Directory credentials, you can enable AD Memberships by setting the "ek_LDAPMembershipUser" flag to "true" in the Web.config. This will force all membership users to authenticate against AD like CMS users do, though they will not have CMS access. With this enabled, however, standard user, non-AD user, authentication will not work. The users will be forced to authenticate against AD. The integration and auto-add options will also apply to membership users in this case and you can use the Login control, or the API to set the AutoAddType or force a login to only allow membership users.
Now, obviously if you choose not to enable AD Authentication, all users are authenticated against Ektron only. No communication to AD controllers is made. If you do not enable "ek_LDAPMembershipUser" all membership users are still authenticated only against Ektron. AD/LDAP authentication does not apply to them.
There is no mix-mode authentication in the system, however. You can have AD enabled with CMS users against AD and Membership against Ektron. Or, you can have AD enabled with CMS users against AD and Membership against AD as well. You cannot have CMS users against Ektron and Membership against AD, nor can you have some users as CMS or Membership against AD and other users against Ektron only. I do believe complex options like these will be available in a future release, but for now, once you start enabling AD Authentication, it becomes an all-or-nothing affair depending on where you set it.
And a very important point that should be made about User Groups: You can enable AD Authentication and manually manage User Groups in Ektron. The groups do not need to match AD User Groups. This means you can define your own groups in Ektron, force users to authenticate against Active Directory, and you can apply permissions to the Ektron Groups, independent of AD Group permissions.
I hope this helps shed some light on the user system.
This may depend on what version of Ektron you're on, but I believe this is an issue with the later versions of Ektron where they added the login logic directly to cmslogin.aspx.cs rather than using the cms:Login server control.
A workaround that I know of requires manually editing the login page (cmslogin.aspx) to prevent users from being automatically added as CMS "authors" using EkEnumeration.AutoAddUserTypes.Author and instead be added as membership users only.
You can also create your own login page to customize the logic and remove the stock login page; whatever you do, backup the stock page first :)
You may be able to play around with this piece:
m_eAutoAddType = EkEnumeration.AutoAddUserTypes.Member; // I added this.
if (bAutoLogin)
{
UserInfo = m_refUserApi.autologInUser(strUsername, strDomain, Request.ServerVariables["SERVER_NAME"], m_eAutoAddType);
}
else
{
UserInfo = m_refUserApi.logInUser(strUsername, strPassword, Request.ServerVariables["SERVER_NAME"], strDomain, strProtocol, m_eAutoAddType);
}
If i recall correctly, one of the few user options still available in AD integration mode is the "lock user" checkbox on their profile.
AD integration can be set up to affect either CMS users or Membership users. CMS users have workarea access whereas Membership users do not. It sounds like you have the wrong option setup.
In a typical Intranet scenario, all your users with AD integration tend to be Membership users. This way they can create content on the site using the Community and Social features.
Your administrators will often have 2 accounts: their regular AD account and a CMS-only account that they can use to administer Ektron through the Workarea.