I have a service account impersonated with the account slave#company.tn.
I inserted the calendar of slave#company.tn to the list of calendars of the service account.
Now I'd like to share that calendar (of the impersonated account) with all the users of the domain company.tn.
--> So that calendar becames in the list of calendars of each user in the domain company.tn
My code after create the calendar is:
AclRule rule = new AclRule();
Scope scope = new Scope();
scope.setType("domain").setValue("default");
rule.setScope(scope).setRole("reader");
// Insert new access rule
AclRule createdRule = service.acl().insert("slave#company.tn", rule).execute();
System.out.println(createdRule.getId());
Am I in the right way ?.
Any suggestion is appreciated.
Big thanks.
You are on the right way, the only problem is the line
scope.setType("domain").setValue("default");:
For type domain, the correct value for the scope would be the actual name of the domain rather than "default".
Keep in mind: The service account needs t be assigned owner, not writer in order to share the calendar with the domain.
Related
We are connecting to Active Directory using this code, inside our ASP.NET MVC 5 app:
string ADusername = System.Web.Configuration.WebConfigurationManager.AppSettings["ADUserName"];
string ADpassword = System.Web.Configuration.WebConfigurationManager.AppSettings["ADPassword"];
using (var context = new DirectoryEntry("LDAP://mydomain.com:389/DC=mydomain,DC=com", ADusername, ADpassword))
Now at the beginning the thought that username/password we are specifying inside the DirectoryEntry should be an Active Directory admin, to be able to get the users' info, but if i try to pass a non-admin user i am able to get all the user's info as well..
My question is: what is the minimum permission for a user to be able to connect to Active Directory using DirectoryEntry ?
Thanks
Without getting excessively detailed, the minimum is simply a user account. By default all users in Active Directory are able to connect and query information from the directory.
If it suits your other requirements, get rid of the username and password as these are bound to get you into a weakened security situation. Instead look at using a (group) managed service account.
The managed service account is designed to provide services and tasks such as Windows services and IIS application pools to share their own domain accounts, while eliminating the need for an administrator to manually administer passwords for these accounts. It is a managed domain account that provides automatic password management.
If you truly need the minimum, you would need to look into the directory security policies, and the permissions on the individual objects you plan to work with.
I try to create events for the users in my organization with a service account for which it is not needed that there is a reminder. Things like public holidays etc...
I add to the event a reminders object to override the default:
EventReminder[] reminderOverrides = new EventReminder[] {};
Event.Reminders reminders = new Event.Reminders()
.setUseDefault(false)
.setOverrides(Arrays.asList(reminderOverrides));
event.setReminders(reminders)
Unit test and functional tests show there are no reminders attached when I check from a service account.
However when I login with user credentials, the default reminders are still visible.
What do I need to do differently so that people are not disturbed early in the morning on a public holiday?
When using the service account you should be aware to impersonate the user and not use the admin account. When an event is created by the admin account the default settings are taken from the user calendar settings. But when you impersonate the user you can turn off the notifications.
From the rest API documentation:
It's possible to specify the email address of the user account with the setServiceAccountUser method of the GoogleCredential factory.
is there any way how to get the list of all usernames for a specific account in GA. And as output it would be shown in Google Spreadsheet.
Moreover, can you find all properties/profiles using GA API the user is having access to?
Thanks in advance.
You can use the User Permissions APIs to list all the users and associated permissions for a particular Account, Property or view.
properties = analytics.management().webpropertyUserLinks().list(
accountId='123456',
webPropertyId='UA-123456-1'
).execute()
For your inverse question of requesting all the accounts, properties and views to which a user has access, you can use the account summaries API to list all the account details for the Authenticated user.
account_summaries = analytics.management().accountSummaries().list().execute()
I'd like to use the Meteor.loginWithGoogle() tool to authenticate users, but is there any way to limit it to a specific (Google Apps) domain?
I could check after the user is authenticated using the returned email, but is there a way to do this at the login stage with some parameter for Google login?
I dont think its possible right now.
There is a pull resquest to partly add that functionality: https://github.com/meteor/meteor/pull/1332
The issue with that pull request seems to be that it only fixes the client side of thinges (ie. it only shows accounts from the selected domain when the user logs in).
But it does not add any server side checks.
Im using the following workaround:
In a .js file in the sever folder I have the following code:
Accounts.validateNewUser(function (user) {
if(user.services.google.email.match(/example\.org$/)) {
return true;
}
throw new Meteor.Error(403, "You must sign in using a example.org account");
});
This prevents accounts from being made for domains different from example.org.
If you want to only allow certain users from your domain, you could also add a whitelist collection that defines user ids from your Google Apps account. This way you can restrict access to only certain users, get single sign-on functionality, and can pre-set user roles and properties for your app before users even create their accounts.
Use the Accounts.onCreateUser(function(options, user){}) callback for that since it allows you to define additional user properties.
I am writing a web app for a client. Users will have a one-time key that they will use to initially identify themselves to the app. Once the app verifies that the key is valid it will take them to a page where they can create a normal account to use for all subsequent logins. The create-account page should only be accessible after entering the key and shouldn't be accessible otherwise. I.e, it shouldn't be accessible to users logged in with a normal account.
This is asp.net 3.0 using a custom membership provider.
My plan is to create a temporary account based on the key and authenticate the user with that account. This allows them access to the create-user page (which is protected with a location tag ) where they can create the formal account. I then authenticate them with their new account and delete the temporary account.
The flow is: the user goes to a page where they enter the key. If the key is valid I create the temporary account, call FormsAuthentication.SetAuthCookie, and redirect to the create-account page. This all works, although it seems a little complicated.
The problem is that the create-user page is available to any authenticated user; I only want it available during the time between entering the key and creating the formal account. So I thought I'd create a special role for the temporary account and make the create-user page accessible only to that role and none other. I created my own Principal object with a special role and tried setting it when I authenticate the temporary account but I can't get that to work.
I'm really hoping I don't have to write a custom role provider just to do this.
How can I make this work? There's gotta be a simpler way!
Why not simply create the real account when they enter the key. Assign it some random name and then let them change the name and other details. Then you don't need the create user page, just the enter key page and an account details editing page. If you're concerned about getting the account details filled in, you could set it up (perhaps via code on a MasterPage) so that incomplete accounts always get redirected to the edit details page until the details are entered.
Or, you could have them enter the required details in addition to the key code on the enter key page and simply use those details when creating the account.
My advice would be to avoid the use of temporary accounts when validating the user. Instead, generate your own logic for validating the sign-up key. Then, at the head of the page, you can check whether the user is an authenticated user (SetAuthCookie has been called) and jump to a different page if this is true.
You may even be able to change the page access to forbid this page to authenticated users (I know you can disable accounts for unauthenticated users but I'm not sure if you can go the other direction).
The key, though, is to avoid relying on the membership provider when, in fact, the user is not yet a member!
Assign an "incomplete" role when authenticating against the temporary token, then restrict access to only that role... when the account is created, send them to a re-login page (terminating the authentication token). This will simplify your security model.