I am wondering what the criteria are for Azure PIM Access Reviews recommendations? In the documentation it gives an example of an interactive user not signing in for the last 30 days. Do the PIM Access Reviews look at who hasn't activated their eligible role(s)? Is there a corresponding report that could be pulled to view anyone who has not requested to elevate their privileges in the last x days?
You can configure Security alerts for azure ad PIM if the user goes over specified number of days without activating the role. When an alert is triggered, it shows up on the Privileged Identity Management dashboard. Select the alert to see a report that lists the users or roles that triggered the alert. We have three levels of severity in security alerts.
High: Requires immediate action because of a policy violation.
Medium: Does not require immediate action but signals a potential policy violation.
Low: Does not require immediate action but suggests a preferable policy change.
We have a default rule called Administrators aren't using their privileged roles you may configure this alert to get the list.
Why do I get this alert?
Users that have been assigned privileged roles they don't need increases the chance of an attack.
Trigger: Triggered if a user goes over a specified number of days without activating a role.
Number of days: This setting specifies the maximum number of days, from 0 to 100, that a user can go without activating a role.
Prevention Assign privileged roles only to users who have a business justification.Schedule regular access reviews to verify that users still need their access.
How to fix? Review the users in the list and remove them from privileged roles that they do not need.
Security alerts for Azure AD roles in PIM - Azure AD | Microsoft Docs
You can also retrieve the group membership information and users who are activated by using power shell commands or scripts
Here are some references to use power shell commands
https://learn.microsoft.com/en-us/azure/active-directory/privileged-identity-management/powershell-for-azure-ad-roles
https://practical365.com/powershell-script-to-report-rbac-role-group-membership/
Related
I need some help understanding the behavior of AD and the security around it.
In a nutshell I have a requirement to automate just in time elevation to certain privileged groups, where Domain Admins is one of the groups we need to add membership to.
Here is a summary on the way I set things up
I created a new group called DomainAdminJit which is a member of "Domain Admins", I add a service account as a delegate to DomainAdminJit to modify membership where I expect to add users to this group instead of the domain admin group directly, for organization purposes mainly.
This works fine but a few minutes later all permissions are to the service account are being stripped, researching this turms out to be done because the AdminSDHolder is reverting those permissions.
My initial reaction was to add the service account with write properties and write permissions to the AdminSDHolder container, but somehow that doesn't work.
I do see the service account now at the DomainAdminsJit group however I get insufficient rights when attempting to add a user to the DomainAdminsJit using that service account.
What am I missing and how do I ensure that service account is always able to add members to a group that is a member of Domain admins and not have the permissions revert?
Your help would greatly be appreciated
Thank you
I'm creating a set of hands-on lab users in my Azure AD for access to Azure Labs. We will reuse these user accounts (and reset the passwords after every lab session).
My challenge is that these users are being required to configure MFA. Which I THINK is called the Azure AD Interrupt Mode described here.
Is there a way to exclude these group of users from being required to set this up?
I think this can be disabled entirely by navigating to Azure AD - Default Directory - Properties - Manage Security Defaults (right at the bottom of the page) - Enable Security Defaults - set it to No.
If it's per user basis, then Navigate to Azure AD - All users - Per User MFA - this will list all the users and then you can select "n" number of them to either enable or disable MFA.
// Answering my own question and hope it helps someone.
The first and obvious step is to disable MFA. This is described in this link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates
After this, however, you may still face the interrupt wizard as shared in the screenshot of the question above. This is due to Self-Service Password Reset (SSPR) being enabled. If SSPR is enabled, then MFA is still required for them to be able to do a password reset.
Solution 1: If you want SSPR enabled, then create a Conditional Access policy requiring MFA upon sign in.
This way, MFA is only triggered when user wants to do an SSPR.
For this lab user scenario, you will still have to set-up MFA one-time for each of the users (you may use the same contact details).
Extra note: I tried setting the MFA details by bulk using PowerShell. However, it is not possible to set an MSOL user object's StrongAuthenticationUserDetails property.
Solution 2: Disable SSPR or limit to selected users using AD groups
Don't include the lab users in the selected users group. Since SSPR is not allowed for these users, the extra MFA details won't be asked of these users anymore.
Drawback: The setting is to include user groups which should have SSPR. There's no option to exclude just the lab users.
Solution 2 works for me but may not work for everyone.
When using the graph explorer I am able to get results from some of the API's. However not able to get when requesting for reports
For Example, this works perfectly fine;
https://graph.microsoft.com/v1.0/users
However, calling the below report related request results in an error "We do not recognize this tenant ID ... Please double-check the tenant ID and try again." I am facing this issue for any such call for reports.
https://graph.microsoft.com/v1.0/reports/getOffice365ActiveUserDetail(period='D90')
Is there some issue with App Registration which is causing this? The error message for checking the TenantID is totally misleading as the token is same in both the cases and I am not doing anything different between the two calls. Would appreciate any guidance.
Try checking these.
Try the request after giving some time like 48 hrs approximately as
it might take a little time for the tenant id to propagate across all
the instances and reflect in Microsoft graph api.
Check if you have given valid tenant ID
check tenant expiration (as admin account)
Else check if required permissions are set.
Reports.Read.All permission is needed to call this API.Refer Microsoft
Graph permissions
Please add the Delegated permisson /the Application permission and test it again. See Microsoft Graph v1.0 | Microsoft Docs
If that’s done already check if admin consent is provided .
( Reports.Read.All permission allows an app to read all service
usage reports without a signed-in user. Make sure to check if you
granted the permission(by clicking Grant Permissions from admin
account).
See reports-permissions
References:
Similar thread
concept-reporting-api
Update:
This error may occur when the usage report is not ready .Because if
the tenant is new , it might take sometime( upto 48 hours) for
the report service to pick it up and start generating reports.
You must be able to test it manually from O365 Admin
Portal.Portal.office.com -> Admin Tab -> Show all -> Reports ->
Usage
Other wise , you may contact support to raise a request.
I am currently working on a AD installation where there are about 45,000 accounts and about 60+ global catalogue servers, some accounts are active some are disabled. Some active accounts are service account which don't appear to login as the lastlogondate is several months old.
If I disable some of the service accounts which do not login the application stops working so I know the application is authenticating to AD somehow.
My question is how can I determine which account have been used to authenticate but have not actually 'logged in'? Is there an attribute I can query or can I set it somehow that AD writes to the event log?
Simply speaking, lastLogonTimestamp is the right attribute to find inactive accounts.
See following link for descriptions on different related attributes:
http://social.technet.microsoft.com/wiki/contents/articles/22461.understanding-the-ad-account-attributes-lastlogon-lastlogontimestamp-and-lastlogondate.aspx
Just copied from above link, using PowerShell, you can get inactive users (inactive for AROUND 90 days, note lastLogonTimestamp is only an approx value) by calling:
Search-ADAccount -AccountInactive -DateTime ((get-date).adddays(-90)) -UsersOnly
For the last logon time from Hyena, I suspect it is inaccurate.
(I never use Hyena before, so just a guess.)
From the following link:
http://www.systemtools.com/HyenaHelp/index.htm#userlogoninfo.htm
Seems by default it only get the last logon info from one DC only. If they get this info from lastLogon attribute instead of lastLogonTimestamp (very likely, otherwise the "Check All Domain Controllers" option is meaningless), it will only get the logon time on this specific DC only. So if those service account are always using DC1 in recent authentications but you connect to DC2 to get the logon time, you will only get a very old time (or none if it never use DC2 to authenticate).
I don't know what function or technique you are using in Hyena to get the 'last logon' information, but as indicated by others, the AD attribute 'lastlogontimestamp' will get you a fairly accurate date/time (~within 10-day accuracy) of the last use of an account. This attribute can be added to any query in Hyena for all of your users. You can also export out the service information on all computers and servers, to see what accounts are being used.
If you need additional assistance, contact SystemTools Support - support#systemtools.com
We are always ready to support our customers.
(I am with SystemTools (Hyena) support)
I can check user in active directory, if he exist then I give him permission to open app window, but what if an application has many levels of permission? Do I create special groups of permission in active direcotry and check if user belongs to one of them? . Can application log in automaticaly, or there is always need to enter password?
Active Directory can fulfill two related but seperate functions for an application: Authorization and Authentication.
Authentication is validating that the person using your application is a valid user. If you have the user's credentials (i.e. the application prompts the user for their username and password), you can authenticate them against AD by attempting a connection using their username/password.
Authorization is what lets you determine the level of permissions a particular user has in your application. Active Directory groups are a relatively straightforward and flexible way to implement the various permissions levels. Typically, I will create very fine-grained permissions groups that represent each securable action users can perform in the application (i.e. CanDeleteWidgets, CanAddWidgets, CanEditWidgets ). Then create functional or role groups where you place the users for that role (i.e. Managers, Coordinators, Technicians, etc). Finally, you just nest the role groups into the permissions groups so if, for example, the business requirement is that Managers can delete widgets, you would add the Managers group as a member of the CanDeleteWidgets group. While this may seem more complex, it makes it extremely simple to respond to changing business security requirements (i.e. "Technicians need to be able to delete widgets" - Piece of cake. Add the Technicians role group to the CanDeleteWidgets permissions group and you're done).
As far as logging in automatically, yes, there are a number of ways you can automatically log in a user. For winforms apps, you should just be able to grab the currently logged in user and use that. For web apps, if you can use integrated authentication, you end up with the same thing. Your web server will handle the authentication piece and send over the DOMAIN\USERNAME of the user in a server header variable.