I am connecting to CRM Online v9.0 using XRM Tooling Connector.
I am trying to update a Contact using WebAPI. Once the contact is updated, the a workflow is triggered that sends an Email to the Contact. However I am getting - User does not have privilege send as. When I check in the Code, CallerID for service object is set to {00000000-0000-0000-0000-000000000000}. I think this is the reason why my workflow does not execute successfully.
Can someone please help me with this.
Thank you in Advance.
I think this is a Security issue. There are specific security privileges required to act on behalf of or send emails on behalf of other users.
These privileges are on the Business Management tab in the Security Role.
In addition to this, the impersonated user must have also authorised emails to be sent on their behalf.
This setting is located in the the impersonated users personal settings
Related
I have been working with the Android Management API to try and manage the policy of my company's existing enterprise. My company account has the Owner role within the organization and the roles Owner and Service Account Admin for the service account mentioned later.
I followed the Quickstart Guide to get familiar with the API and made some modifications for a more permanent solution along the way such as creating a service account with the Android Management User role via the Google Cloud Platform and generating a JSON key to acquire credentials rather than going through the OAuth2 flow like in the guide. This allowed me to authenticate properly, but when it comes time to patch the policy as such,
androidmanagement.enterprises().policies().patch(
name=policy_name,
body=policy_json
).execute()
I get the following error:
<HttpError 403 when requesting https://androidmanagement.googleapis.com/v1/enterprises/XXXXXXXXX/policies/<policy_name>?alt=json returned "Caller is not authorized to manage enterprise.". Details: "Caller is not authorized to manage enterprise.">
I have verified that the service account I am authenticating with has the Android Management User role, and thus has the androidmanagement.enterprises.manage permission.
I have also attempted to make this call with an elevated admin role in the organization.
Is there a chance that I need to have created the enterprise with my own account to manage the enterprise? The guide suggests that an organization can create multiple enterprises. In which case, would I need to create a new Google account not associated with my organization's enterprise and create a new enterprise that way?
It is advisable to use your own google account to call Android Management API since your organization account may not be compatible with the quickstart.
To access the Android Management API your service account requires the androidmanagement.enterprises.manage permission, which can be granted by the Android Management User role (or roles/androidmanagement.user). Kindly check this link for details regarding creating a service account.
Please keep in mind that the enterprise you created as part of the colab instructions can only be managed using the colab itself. To allow your cloud project to manage an organization, you will need to create one using the client configuration from your cloud project.
I'm having an issue, I have an On-Premise CRM Dynamics environment with Server Side synchronization, the sync works fine.
When creating appointments the System Users receive a meeting invite, but this is not sent to contacts in the system (even though some of them are emails from the same AD).
Is there an error log I can check, or some extra configuration needed in exchange server for it to work?
P.S. I'm attaching the current configuration.
When using server side synchronization, the account used as part of the authentication setup must have elevated permissions to send email on behalf of others or you need to modify the user's settings to allow others to send emails on their behalf, this could be what is causing the issue, also could you open up the emails that were not sent, they should also have an error message describing why the sending the email failed.
anyone can help me understand how to authenticate to exchange server for a server application on behalf of a user? My use case is to sync the mails of a user's mailbox and update the read state and deleted states with our server. Exchange online has rest API and Oauth to authenticate but that does not work with On Premise account? Is there a way I can authenticate for all the different deployments[exchange online and on premise] and access the Outlook mail?
We need to way to authenticate the user without trying to getting any credentials, so that our service can access mailbox without any need for prompt.
Seems your best bet would be to use impersonation, which would work in either EXO on on-prem. Your sever would require a service account in Exchange, then authenticate with the creds for that single account. Before synching mailbox, it would set the impersonation ID to the MB it was synching. Of course an Exchange admin would need to set up impersonation rights for your service account for every MB your service would examine, but that's easily done with a little PowerShell, and willingness on their part, of course.
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
"Microsoft CRM could not log you on to the system. Make sure your user record is enabled and that you have been assigned at least one security role. For more information, contact your system administrator."
When I RDP into the server and try Microsoft CRM Workflow Manager/Monitor with http or https connectivity, it doesn't work. "The specified Microsoft CRM server is not responding. This might happen if it is currently unavaliable, it is not a Microsoft CRM server, or you are not a valid user. Contact your sys-admin."
This is a Microsoft CRM v3.0 / Microsoft SQL server 2005 box, Active directory is on a seperate box..
When I right click Microsoft CRM Worlkflow Service, properties, log on: it shows "crmtestuser" and a password. I did not RDP or try logging in as that crmtestuser, but I am Admin... Could this be a clue?
What can I try?
Does the user that you're logging onto the machine have an account in CRM? If so, does that account have any security roles assigned to it?
Also, in CRM 3.0, there are special permissions given to the user that installed CRM. If you can't give permissions to the a user because you can access CRM, try using the same user that installed CRM, and with that user logged in, give Administrator permissions to other users.