Crm 2011 test the crm4 metadata endpoint - dynamics-crm-2011

I'm having trouble with a third party product that suppose to connect to a CRM2011 CRM4 metadata endpoint. Basically the product is AVAYA EMC version 6.3.1, I'm aware that this specific version is not compatible with CRM2011, but the documents released by the company are not really clear if this involved the CRM2011 CRM4 metadata endpoint.
Long story short, there is this plugin ASMSCRMGuiPlugin.dll that is not able to authenticate the metadata endpoint provided as:
(this should be the metadata attribute endpoint for crm4)
http://server/MSCRMServices/2007/MetadataService.asmx
to confirm that the endpoint was working i wrote a console that was querying the metadata endpoint on that address with the provided credentials (the ones that in the plugin were not working), and i was able to retrieve all the contacts attributes.
Now I'm not a crm4 developer and I entered the CRM world when 2011 was already established, is there any setting on CRM2011 side that I have to tweak to allow this component to work?
I will append the code i used to connect to the metadata endpoint. Is there any other way for me to prove that is not a crm configuration issue? Anyone out there ever managed to configure AVAYA EMC6.3.1 with CRM 2011, using the endpoint crm4?
CrmAuthenticationToken token = new CrmAuthenticationToken();
token.OrganizationName = "Org";
token.AuthenticationType = 0;
MetadataService mdSevice = new MetadataService();
mdSevice.Credentials = new System.Net.NetworkCredential("User", "Passw", "domain");
mdSevice.Url = "http://org/MSCRMServices/2007/MetadataService.asmx";
mdSevice.UseDefaultCredentials = false;
mdSevice.CrmAuthenticationTokenValue = token;
RetrieveEntityRequest entityRequest = new RetrieveEntityRequest();
entityRequest.RetrieveAsIfPublished = false;
entityRequest.LogicalName = EntityName.contact.ToString();
entityRequest.EntityItems = EntityItems.IncludeAttributes;
RetrieveEntityResponse entityResponse = (RetrieveEntityResponse)mdSevice.Execute(entityRequest);
Console.WriteLine("Retrieved fields: ");
EntityMetadata retrievedEntityMetadata = entityResponse.EntityMetadata;
foreach (AttributeMetadata att in retrievedEntityMetadata.Attributes)
{
{
Console.WriteLine(att.LogicalName);
}
}

Related

DocuSign - View Form Data

Another company we partner with sends us new client information via DocuSign envelopes completed by those clients. I am attempting to extract the form data from the document, either via the PDF or via the DocuSign API. The PDF only appears to have the Envelope ID embedded in it. When I add my account as a CC recipient and try to view the form data in the DocuSign console, I receive an error message:
Additionally, I'm unable to view the form data via the DocuSign API.
{
errorCode: "USER_LACKS_PERMISSIONS",
message: "This user lacks sufficient permissions to access this resource."
}
I've tried accessing via the API at:
/v2/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/tabs
/v2/accounts/{accountId}/envelopes/{envelopeId}/documents/{documentId}/fields
Questions:
Is there a way for a user who is not in the sender's tenant to be able to view the envelope form data?
Is there a way for DocuSign to embed the tab data into the PDF for extraction?
Is there another approach I'm not considering?
If the user is cc to the envelope using the same userId and email combination that is on their account, then that user also can use the API to gain account information. (account is what you call "tenant.")
If the user is not on the envelope and you just receive the PDF some other way, then you cannot use the API to obtain information about the envelope because that is limited only to recipients of the envelope.
#Inbar-Gazit was kind enough to do some digging internally at DocuSign, and after a bit of back-and-forth, discovered that this is possible using the SOAP API with the RequestEnvelope and RequestEnvelopeV2 methods. I'm unsure if there's any advantage to using one method over the other. Both also have async methods.
https://developers.docusign.com/docs/esign-soap-api/reference/Status-and-Managing-Group/RequestEnvelope
Some quick-and-dirty C# validated that this will indeed work. I validated this both as the sending account (which also works via REST) and the CC recipient account (which did not work via REST).
var authString = $"<DocuSignCredentials><Username>{_userName}</Username><Password>{_password}</Password><IntegratorKey>{_apiKey}</IntegratorKey></DocuSignCredentials>";
var client = new DSAPIServiceSoapClient();
using (OperationContextScope scope = new OperationContextScope(client.InnerChannel))
{
HttpRequestMessageProperty httpRequestProperty = new HttpRequestMessageProperty();
httpRequestProperty.Headers.Add("X-DocuSign-Authentication", authString);
OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = httpRequestProperty;
EnvelopeStatus status = client.RequestStatusEx(_envelopeId);
Console.Out.WriteLine("Subject: " + status.Subject);
// RequestEnvelope Method
var envelope = client.RequestEnvelope(_envelopeId, false);
var testTab = envelope.Tabs.FirstOrDefault(t => t.TabLabel.Contains("Test"));
if (testTab != null)
{
Console.WriteLine($"Tab {testTab.TabLabel}: {testTab.Value}");
} else
{
Console.WriteLine("Tab not found.");
}
// RequestEnvelopeV2 Method
var requestOptions = new RequestEnvelopeV2Options() {
IncludeAC = false,
IncludeAnchorTabLocations = true,
IncludeDocumentBytes = false
};
var envelopeV2 = client.RequestEnvelopeV2(_envelopeId, requestOptions);
var testTabV2 = envelopeV2.Tabs.FirstOrDefault(t => t.TabLabel.Contains("Test"));
if (testTabV2 != null)
{
Console.WriteLine($"Tab(v2) {testTabV2.TabLabel}: {testTabV2.Value}");
} else
{
Console.WriteLine("Tab(v2) not found.");
}
Console.WriteLine("\r\nDone.");
Console.ReadKey();
}
Output:
Subject: Please DocuSign: Test Envelope
Tab txtDataLabelTest1: Some Data Here
Tab(v2) txtDataLabelTest1: Some Data Here
Done.

Facing "The token contains no permissions, or permissions can not be understood." issue in EWS with Oauth

We have requirement in which we need to add appointment to user outlook account on behalf of that user using delegate access. All mails are in same domain or same network. We are trying this by using Oauth with office365, by creating Azure application and providing application level "calendar read and write" delegate permission.
I have referred https://blogs.msdn.microsoft.com/exchangedev/2015/01/21/building-daemon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow/ article to setup azure application, which will provide me a access token.
While fetching access token I have used following code
private static string GetTokenUsingCertificate()
{
string authority = string.Format("https://login.windows.net/{0}/oauth2/authorize", tenantID); ;
string outlookUri = "https://outlook.office365.com/";
var authenticationContext = new AuthenticationContext(authority, false);
var clientCertificate = new ClientAssertionCertificate(clientId, GetClientCertificate());
AuthenticationResult authenticationResult = null;
try
{
authenticationResult = authenticationContext.AcquireTokenAsync(outlookUri, clientCertificate).Result;
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
return authenticationResult?.AccessToken;
}
above function is providing me access token but when I try to add appointment to user outlook calendar using Exchnage Service, I am getting "The token contains no permissions, or permissions can not be understood." exception.
While adding appointment I am using following code
private void AddAppointment()
{
ExchangeService exchangeService = new ExchangeService();
exchangeService.Credentials = new OAuthCredentials(accessToken);
exchangeService.Url = new Uri("https://outlook.office365.com/EWS/Exchange.asmx");
Appointment appointment = new Appointment(service)
{
Subject = "EWS OAuth: Appointment 2",
Body = "EWS OAuth Auth: Body",
Start = DateTime.Now.AddMinutes(10)
};
appointment.Save(
new FolderId(WellKnownFolderName.Calendar, new Mailbox("mail#outlook.com/")),
SendInvitationsMode.SendToNone);
}
Please help me to resolve this issue.
Blockquote
EWS doesn't allow the same level of OAuth permissions scope (or permission restriction) that the REST API allows for which is one of the big benefit of using REST vs EWS. If you have Office365 why are trying to use EWS over REST ?
To answer the question you will need
OAuth authentication for EWS is only available in Exchange as part of Office 365. EWS applications require the "Full access to user's mailbox" permission.
as per https://msdn.microsoft.com/en-us/library/office/dn903761%28v=exchg.150%29.aspx .

Sending IM with Skype for Business Online from Console App

I am trying to set up a C# console app that can send notifications/reminders to users via Skype for Business online from a generic AD account. I was excited to see the other day that according to this page, UCWA is now supported in Skype for Business online: https://msdn.microsoft.com/en-us/library/office/mt650889.aspx.
I've been trying to follow this tutorial to get this set up: https://msdn.microsoft.com/en-us/library/office/mt590891(v=office.16).aspx. So far I haven't really had much luck... I have my application set up in Azure AD but I get stuck at the "Requesting an access token using implicit grant flow" step of that article (not 100% certain I'm taking the correct actions before that either)... so far I have this:
string clientId = "xxxxxxxx"
string resourceUri = "https://webdir.online.lync.com";
string authorityUri = "https://login.windows.net/common/oauth2/authorize";
AuthenticationContext authContext = new AuthenticationContext(authorityUri);
UserCredential cred = new UserCredential("username", "password");
string token = authContext.AcquireToken(resourceUri, clientId, cred).AccessToken;
var poolReq = CreateRequest("https://webdir.online.lync.com/autodiscover/autodiscoverservice.svc/root", "GET",token);
var poolResp = GetResponse(poolReq);
dynamic tmp = JsonConvert.DeserializeObject(poolResp);
string resourcePool = tmp._links.user.href;
Console.WriteLine(resourcePool);
var accessTokenReq = CreateRequest("https://login.windows.net/common/oauth2/authorize"
+ "?response_type=id_token"
+ "&client_id=" + clientId
+ "&redirect_uri=https://login.live.com/oauth20_desktop.srf"
+ "&state=" + Guid.NewGuid().ToString()
+ "&resource=" + new Uri(resourcePool).Host.ToString()
, "GET",token);
var accessTokenResp = GetResponse(accessTokenReq);
my GetResponse and CreateRequest methods:
public static string GetResponse(HttpWebRequest request)
{
string response = string.Empty;
using (HttpWebResponse httpResponse = request.GetResponse() as System.Net.HttpWebResponse)
{
//Get StreamReader that holds the response stream
using (StreamReader reader = new System.IO.StreamReader(httpResponse.GetResponseStream()))
{
response = reader.ReadToEnd();
}
}
return response;
}
public static HttpWebRequest CreateRequest(string uri, string method, string accessToken)
{
HttpWebRequest request = System.Net.WebRequest.Create(uri) as System.Net.HttpWebRequest;
request.KeepAlive = true;
request.Method = method;
request.ContentLength = 0;
request.ContentType = "application/json";
request.Headers.Add("Authorization", String.Format("Bearer {0}", accessToken));
return request;
}
accessTokenResp is an office online logon page, not the access token I need to move forward... so I'm stuck. I've tried quite a few variations of the above code.
I've been scouring the net for more examples but can't really find any, especially since UCWA support for Office 365 is so new. Does anyone have an example of how to do what I am trying to do or can point me to one? Everything I've found so far hasn't really even been close to what I'm trying. I can't use the Skype for Business client SDK unfortunately either as it doesn't meet all of my requirements.
I came to a working solution using ADAL (v3), with the help of steps outlined at
Authentication using Azure AD
Here the steps, which involve requesting multiple authentication tokens to AAD using ADAL
Register your application, as Native Application, in Azure AD.
Perform autodiscovery to find user's UCWA root resource URI.
This can be done by performing a GET request on
GET https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=yourdomain.onmicrosoft.com
Request an access token for the UCWA root resource returned in the autodiscovery response, using ADAL
For instance, your root resource will be at
https://webdir0e.online.lync.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=yourdomain.onmicrosoft.com
you'll have to obtain a token from AAD for resource https://webdir0e.online.lync.com/
Perform a GET on the root resource with the bearer token obtained from ADAL
GET https://webdir0e.online.lync.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=yourdomain.onmicrosoft.com
This will return, within the user resource, the URI for applications resource, where to create your UCWA application. This in my case is:
https://webpoolam30e08.infra.lync.com/ucwa/oauth/v1/applications
Residing then in another domain, thus different audience / resource, not included in the auth token previously obatained
Acquire a new token from AAD for the host resource where the home pool and applications resource are (https://webpoolam30e08.infra.lync.com in my case)
Create a new UCWA application by doing a POST on the applications URI, using the token obtained from ADAL
Voilá, your UCWA application is created. What I notice at the moment, is that just few resources are available, excluding me / presence. So users' presence can be retrieved, but self presence status can't be changed.
I've been able however to retrieve my personal note, and the following resources are available to me:
people
communication
meetings
Show me some code:
Function to perform the flow obtaining and switching auth tokens
public static async Task<UcwaApp> Create365UcwaApp(UcwaAppSettings appSettings, Func<string, Task<OAuthToken>> acquireTokenFunc)
{
var result = new UcwaApp();
result.Settings = appSettings;
var rootResource = await result.Discover365RootResourceAsync(appSettings.DomainName);
var userUri = new Uri(rootResource.Resource.GetLinkUri("user"), UriKind.Absolute);
//Acquire a token for the domain where user resource is
var token = await acquireTokenFunc(userUri.GetComponents(UriComponents.SchemeAndServer, UriFormat.SafeUnescaped));
//Set Authorization Header with new token
result.AuthToken = token;
var usersResult = await result.GetUserResource(userUri.ToString());
//
result.ApplicationsUrl = usersResult.Resource.GetLinkUri("applications");
var appsHostUri = new Uri(result.ApplicationsUrl, UriKind.Absolute).GetComponents(UriComponents.SchemeAndServer, UriFormat.SafeUnescaped);
//Acquire a token for the domain where applications resource is
token = await acquireTokenFunc(appsHostUri);
//Set Authorization Header with new token
result.AuthToken = token;
//
var appResult = await result.CreateApplicationAsync(result.ApplicationsUrl, appSettings.ApplicationId, appSettings.UserAgent, appSettings.Culture);
return result;
}
Usage code ato retrieve OAuth tokens using ADAL
var ucSettings = new UcwaAppSettings
{
UserAgent = "Test Console",
Culture = "en-us",
DomainName = "yourdomain.onmicrosoft.com",
ApplicationId = "your app client id"
};
var acquireTokenFunc = new Func<string, Task<OAuthToken>>(async (resourceUri) =>
{
var authContext = new AuthenticationContext("https://login.windows.net/" + ucSettings.DomainName);
var ar = await authContext.AcquireTokenAsync(resourceUri,
ucSettings.ApplicationId,
new UserCredential("myusername", "mypassword"));
return new OAuthToken(ar.AccessTokenType, ar.AccessToken, ar.ExpiresOn.Ticks);
});
var app = await UcwaApp.Create365UcwaApp(ucSettings, acquireTokenFunc);
It should be of course possible to avoid hard-coding username and password using ADAL, but this was easier for PoC and especially in case of Console Application as you asked
I've just blogged about this using a start-to-finish example, hopefully it will help you. I only go as far as signing in, but you can use it with another post I've done on sending IMs using Skype Web SDK here (see day 13 and 14) and combine the two, it should work fine.
-tom
Similar to Massimo's solution, I've created a Skype for Business Online C# based console app that demonstrates how to sign and use UCWA to create/list/delete meetings and change user presence. I haven't gotten around to extending it to send IM's, but you're certainly welcome to clone my repository and extend it to your needs. Just drop in your Azure AD tenant name and native app ID into the code.
I think they just turned this on today - I was doing something unrelated with the Skype Web SDK samples and had to create a new Azure AD app, and noticed that there are two new preview features for receiving conversation updates and changing user information.
Now everything in the Github samples works for Skype For Business Online.

Sharepoint claims based vs classic authentication

I have 2 sharepoint sites running out of one sharepoint installation. One site has claims based enabled and the other has classic auth enabled. Both sites also both use Kerberos.
I am using ManifoldCF to connect to these sites to extract the all content as well as the permissions. The ManifoldCF connector connects to the site with classic auth enabled and works as expected. However, trying to crawl the claims based site generates a 401 unauthorised error.
There is a web service package supplied with ManifoldCF that is accessed called MCPermissions.asmx. This file contains the following block of code which sets the user's credentials:
try
{
// Only handle requests for "item". Send all other requests to the SharePoint web service.
if (objectType.Equals(itemType))
{
retVal = GetItemPermissions(objectName);
}
else
{
ServicePointManager.ServerCertificateValidationCallback +=
new RemoteCertificateValidationCallback(ValidateCertificate);
using (SPPermissionsService.Permissions service = new SPPermissionsService.Permissions())
{
service.Url = SPContext.Current.Web.Url + "/_vti_bin/Permissions.asmx";
service.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
retVal = service.GetPermissionCollection(objectName, objectType);
}
}
}
catch (SoapException soapEx)
{
throw soapEx;
}
catch (Exception ex)
{
SPDiagnosticsService.Local.WriteTrace(0, new SPDiagnosticsCategory("MCPermissions.asmx", TraceSeverity.Unexpected, EventSeverity.Error), TraceSeverity.Unexpected, "Error: "+ex.Message+"; SPContext.Current.Web.Url='"+SPContext.Current.Web.Url+"'", ex.StackTrace);
throw RaiseException(ex.Message, "1000", ex.Source);
}
This code is accessed via ManifoldCF correctly, but it seems its the request made in the plugin to /_vti_bin/Permissions.asmx that is causing the 401 issue.
I have tried setting pre defined credentials in the code above using NetworkCredential
("username", "password", "domain") but no luck.
Example:
string webUrl = SPContext.Current.Web.Url;
NetworkCredential myCredentials = new NetworkCredential("DOMAIN\\user", "mypassword", "DOMAIN");
CredentialCache credCache = new CredentialCache();
credCache.Add(new Uri(webUrl), "Negotiate", myCredentials);
service.Url = webUrl + "/_vti_bin/Permissions.asmx";
service.Credentials = credCache;
With the claims based authentication, the username that i enter into ManfoldCF or in the browser authentication gets changed from the regular \ format to the claims username format (e.g. i:0#.w||/).
Does anybody know why claims based would be causing the 401 issue where the classic authentication does not?
Turns out this was a bug with the ManifoldCF 1.2 release. It has been fixed in newer versions.

Crm 2011. How get Current user in mvc application

I have a custom mvc application, what i want to use as a part of crm 2011
(for example i have a button at crm panel, which call action at my mvc application)
Can I get user credentials, which log in in crm and press button?
I use this code to run organization service. But WhoAmIRequest return system or null (depend of impersonate property in web.config)
var organizationUri = new Uri(Configuration.OrganizationUri());
var credentials = new ClientCredentials();
credentials.Windows.ClientCredential = (DefaultCredentials != null) ? DefaultCredentials : CredentialCache.DefaultNetworkCredentials;
IServiceConfiguration<IOrganizationService> orgConfigInfo = ServiceConfigurationFactory.CreateConfiguration<IOrganizationService>(organizationUri);
var service = new OrganizationServiceProxy(orgConfigInfo, credentials);
WhoAmIResponse response = (WhoAmIResponse)service.Execute(new WhoAmIRequest());
service.CallerId = response.UserId;
You could read the current Username
User.Identity.Name
and compare it with the domainname in MS CRM.

Resources