As mentioned in the title, Is there anybody know how to get member list belong to a created google group using AdminSDK without super user's right. I tried on GAE but always received the following error :
「Not Authorized to access this resource/api」
Thank you!
You dont need superuser rights, thats just one way.
If the user is owner/manager of the group, she can see membership.
Also might work if you make group membership visible to all but i haven't tried it.
Related
While trying to access online meeting in order to get the start and end time of the meetings.i am getting below error.
Any help is highly appreciated. Thanks
Note : I am able to create the meeting and access it but I want to record the meeting start and end time too.Sometimes the error is ID is malformed althrough I am using the meeting ID returned from the Graph only which is being created.
Please try /me/onlineMeetings/{meetingId}.
Microsoft Graph Explorer users Delegated permission, which mainly takes effect on /me endpoint. If you want to use /users/{userId}/onlineMeetings/{meetingId} , make sure /users/{userId} is the current signed-in user.
Please don't query the online meeting of other users. It is only supported by Application permission.
The required Delegated permissions are OnlineMeetings.Read, OnlineMeetings.ReadWrite.
You can add them like this:
Not quite sure if this has been asked. In Salesforce, I can see within the object explorer and within the fields and relationships, all entries however if I perform in postman a:
https://eu40.salesforce.com/services/data/v50.0/sobjects/amazonconnect__AC_ContactTraceRecord__c/describe
and copy the results within a test document and look for a particular field I cannot find it. Is there a security setting within the fields from being accessed though a rest api?
Thanks,
the api user does not seem to have enough rights. Add the apiuser as an AC_Administrator and give it a try.
I'm trying to sync users/groups that sit behind Okta in Active Directory. Specifically, I'd like to get all groups a user belongs to, upon login to a third party application.
Looking at the Okta API documentation (http://developer.okta.com/docs/api/resources/groups.html) I see that I could accomplish this by performing the following operations (in pseudo-code):
FETCH ALL GROUPS (using List Groups operation)
FOR EACH GROUP
FETCH A LIST OF USERS (using List Group Members operation)
For my purposes this seems very inefficient, but I can't find a better way of doing this by looking at the documentation.
Ideally, what I would like to do is:
FETCH ALL GROUPS FOR A GIVEN USER ID
Is there any way I could accomplish this ?
Any help is appreciated. Thanks.
I found the answer: the Get Member Groups API call does this exact thing. It's under Related Resources here: http://developer.okta.com/docs/api/resources/users.html
https://developer.okta.com/docs/reference/api/users/#get-user-s-groups how about that?
[GET] /api/v1/users/$userid/groups
It's also possible to get this list when the user logs in into an app via SAML.
Add a Group Attribute Statement with filter Matches regex and value .*.
You will get the user's groups as part of the XML.
I want to do a role based access for the pages in AngularJS.
Based on the role pages should be shown to the user.
Can any give me an example? Which should be a best solution.
To access the page based on the role is very easy.
Suppose if the web/dashboard have three roles like admin, support, employee.
assign the field as userrole to the users.
Now assign the roles for those pages as ng-if="userrole=='admin'" or vice versa
now based on the roles the pages are accessible
I'd suggest you take a look at (in the following steps):
Decide on an approach for accessing the current users role.
Look into ui-router, specifically it's Resolve method.
Run some third function inside the Resolve method to see if the user is of the correct role, and handle your cases in what way you will.
Something I worked on a while back had an Authenticate method running in the Resolve method, you may want to have a look at that for reference. This was not role based however, but it may give you a nudge in the right direction.
Routes:
https://github.com/kasperlewau/metalmarket/blob/master/app/assets/javascripts/config/routes.js
Auth Service: https://github.com/kasperlewau/metalmarket/blob/master/app/assets/javascripts/app/services/auth.js
If anyone has a better idea for role based / logged-in based authentication, I'm all ears.
I have a Debian Squeeze system which is using libnss-ldap to bind to a 2008 Active Directory domain controller to look up users and groups. Everything works fine, except for some reason anyone who is in the Domain Admins, Enterprise Admins, or Schema Admins group does not get the correct group memberships. They get only the *Admin group, and no others (unless there are local groups that apply, which do show).
Stranger yet, a "getent group" shows all the correct group memberships for the user, but an "id " or "groups" (when running as the user) doesn't. We use a domain group for sudo access, and this user is unable to use sudo because it fails to see the group membership. As soon as the *Admin membership is removed, lookups work correctly.
I suspected maybe this was an AD security feature, but we have FreeBSD systems using nss-ldap on which these users' group memberships resolve correctly. There is nothing in the logs to indicate why these lookups don't return the normal results, and I haven't been able to find anything via Google to help shed light on the situation. Is anyone else using libnss-ldap in Debian to connect to an AD who can try to confirm this behavior?
Edit: I have confirmed using ldapsearch that the AD is returning the correct results. I also stopped nscd to make sure it wasn't interfering. Any user in Domain Admins sees only his primary group, local groups, and Domain Admins.
BTW, I think this is the issue:
http://support.microsoft.com/kb/976063
I have had this problem also.
I found it eventually about 18 months ago. It is a security feature of Microsoft. There is a service that runs once per hour and removes the admins from the LDAP search. If you do a query as anonymous, you will receive the correct answer for 1 hour. After one hour you will receive nothing. If you log in as a domain user, you will receive the correct information. That is why you get different results.
I do not at this point remember the service name but I am searching for it now. I found it originally on Microsoft tech net about 18 months ago, but by now, I don't remember it.
The point was that the only answer to it is
Disable that service and it does many other security items so that is not a good idea.
Change the LDAP searches to run under a domain user's log in (we have done that on some users)
Create a bogus duplicate contact with the same information for each of our admins. This is probably the easiest and quickest, but the most prone to developing wrong information over time.
The rational of this security feature is to hide all domain admins from random anonymous searches so their credentials can't be compromised by an encyclopedia password attack.
Calvin Thomas
My answer was deleted, but the problem was, in fact UAC as described in http://support.microsoft.com/kb/976063. The issue is that Domain Admins, when UAC is enabled on the DC, actually exist in two states. One that is a member of the domain admins group (i.e., the UAC 'shadow' user) and another that is the normal user. It appears that the DC only returns the former when queried with LDAP. By creating a new group, making that group a member of Domain Admins instead of the accounts themselves, and putting the accounts in the new group, the problem was resolved.