As per MS article only GroupMember.Read.All permission is required to list the group owner. I assigned this API permission to my Azure AD application. however, when I run the below query it throws the 403 error. It works without "$expand=owners" parameter
https://graph.microsoft.com/v1.0/groups?`$expand=owners
Error
Invoke-RestMethod : The remote server returned an error: (403) Forbidden.
Also, the above graph query works if assign Group.Read.All permission. But I don't want to assign this permission it will allow the application to read calendars, conversations, files, and other group content of all groups.
Please note that we have more than 2 million groups in Azure AD. So running two separate queries for the group and owner will be very time-consuming.
I tried to reproduce the same in my environment by granting GroupMember.Read.All permission and got the 403 error like below:
https://graph.microsoft.com/v1.0/groups?$expand=owners
Response:
Using GroupMember.Read.All permission, you cannot expand the owners($expand=owners) but can list the owner of specific group like below:
https://graph.microsoft.com/v1.0/groups/GroupID/owners
Response:
Please note that you must need Group.Read.All permission to expand owners($expand=owners) that includes owners of all groups in response.
https://graph.microsoft.com/v1.0/groups?$expand=owners
After granting Group.Read.All permission, got the response successfully like below:
Response:
References:
Use query parameters to customize responses - Microsoft Graph | Microsoft Docs
My SNOWFLAKE database is SSO login enabled and the SSO connectivity works perfectly fine when I connect through my chrome browser.
When I try to connect to SNOWFLAKE database using DBeaver (external browser) I get the below error .
NOTE : I can confirm that I am able to see the identity verification (through explorer browser) page and the identity has also been verified. I feel the issue happens when the explorer browser confirms the identity verification back to DBeaver.
Can anyone please help ?
The above error is a generic message and could be seen due to misconfigurations either at the identity provider end or at the service provider end.
It is recommended to verify the configurations for your identity provider and make sure all the steps are performed correctly.
Below could be the common reasons for this error, However, there might be other improper configs as well which could lead to a similar error message.
a. Mismatch in user configuration details at Idp(Identity provider) and Snowflake.
b. SSO certificates are incorrect.
Solution
a. Username configured at the Identity provider end should match with the login_name at snowflake end for that user. For instance, If the SAML response shows NameID as abc#xyz.com. Then login_name configured at Snowflake end should be same as abc#xyz.com
SAML response snippet:
abc#xyz.com
Set the login_name same as the NameID configured at the identity provider side.
alter user set login_name='abc#xyz.com';
b. SSO certificate configured at Snowflake end should match with the certificate configured at the identity provider end.
Note:
The certificate value contains a number of new lines. Remove the new lines, forming a certificate value with a single line.
If the above suggestions did not help then please check the error codes for the failed login attempt in Snowflake Information Schema using the below query. And check the reason for that error code here. The below query retrieve up to 100 login events of every user your current role is allowed to monitor in the last hour and you can modify it appropriately.
select * from table(information_schema.login_history(dateadd('hours',-1,current_timestamp()),current_timestamp())) order by event_time
We have an application which parses the Audit Logs emitted by Azure AD. More specifically we are parsing the 'Update application' log to detect when a new Role has been added to an Application (see example below).
We would like to find out more information about the "DirectAccessGrantTypes" and "ImpersonationAccessGrantTypes" fields. If someone can point us to documentation for this that would be great.
[{"EntitlementEncodingVersion":2,"EntitlementId":"654a4f1f-1b7f-4354-a6d6-fcf7346af0ec","IsDisabled":true,"Origin":0,"Name":"Data Manager","Description":"Manager for test app","Definition":null,"ClaimValue":"DataManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"3d03256d-cf0c-4553-b8af-98d7ebbee1f2","IsDisabled":false,"Origin":0,"Name":"Application Manager","Description":"Admin for test app","Definition":null,"ClaimValue":"ApplicationManager","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[20],"ImpersonationAccessGrantTypes":[],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]},{"EntitlementEncodingVersion":2,"EntitlementId":"88d0d3e3-b661-4760-aea3-f4548db1ff96","IsDisabled":false,"Origin":0,"Name":"Read","Description":"Allow users to add a admin consent","Definition":null,"ClaimValue":"Read","ResourceScopeType":0,"IsPrivate":false,"UserConsentDisplayName":null,"UserConsentDescription":null,"DirectAccessGrantTypes":[],"ImpersonationAccessGrantTypes":[{"Impersonator":29,"Impersonated":20}],"EntitlementCategory":0,"DependentMicrosoftGraphPermissions":[]}]
From article > View reports & logs in entitlement management - Azure AD | Microsoft Docs
When Azure AD receives a new request, it writes an audit record, in
which the Category is EntitlementManagement and the Activity is
typically User requests access package assignment. In the case of a
direct assignment created in the Azure portal, the Activity field of
the audit record is Administrator directly assigns user to access package, and the user performing the assignment is identified by the
ActorUserPrincipalName.
Application Impersonation is basically an administrator-managed, not user-managed permission.
Impersonate access grants logs gives information ex:count., of users given consent by the admin to access the application to impersonate user.
ImpersonationAccessGrantTypes gives count or info of access grants by admin on behalf of user whereas DirectAccessGrantTypes gives info about the users who directly access the application ,as they are already assigned by admin.
Reference:
Multiple Client applications authorisation to WebApi (microsoft.com)
I have a replication set up with pull subscribers and it's deployed in our corporate domain. I have requested to create a dedicated account to run this replication off of.
On a pull subscription client in Sql Agent job I get this error:
Message
Unable to start execution of step 1 (reason: Error authenticating proxy DOMAIN\username, system error: Logon failure: the user has not been granted the requested logon type at this computer. ('Access this computer from network')). The step failed.
Where DOMAIN - is my domain name and username is this replication username that I requested from our admins.
This replication user can access both the distributor and the share folder where snapshots are stored. It also has this specific permission 'Access this computer from network' inherited from the group it's in.
Anyone encounter this sort of problem?
It turned out that the requested user wasn't added to a group that has all the necessary permissions. And so I've been struggling with this problem for several hours at which point I decided to go to our network administrator and see to it that the user was actually in the proper group. So yeah, I guess the message is right, a user has to have this permission 'Access this computer from network'. So, this basically answers my own question. Phew!
I have file writing permission denied problem in my web application,
below is the error i'm getting
Access to the path 'c:\inetpub\wwwroot\autohyperlink\files\test.txt' is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path 'c:\inetpub\wwwroot\autohyperlink\files\test.txt' is denied.
ASP.NET is not authorized to access the requested resource. Consider granting access rights to the resource to the ASP.NET request identity. ASP.NET has a base process identity (typically {MACHINE}\ASPNET on IIS 5 or Network Service on IIS 6) that is used if the application is not impersonating. If the application is impersonating via , the identity will be the anonymous user (typically IUSR_MACHINENAME) or the authenticated request user.
To grant ASP.NET access to a file, right-click the file in Explorer, choose "Properties" and select the Security tab. Click "Add" to add the appropriate user or group. Highlight the ASP.NET account, and check the boxes for the desired access.
the error is here
Line 130: FileStream file1 = new FileStream(Server.MapPath("~\files\test.txt"), FileMode.Create, FileAccess.Write);
how can i solve this problem
please help me
Thanks
I dont mean to be derisive but have you tried doing what it says and granting the worker process read/write access to that folder/file?