Oracle IAM/WNA protocol fallback to form-based logon page fails when Microsoft Online Services Sign-In Assistant is installed - single-sign-on

First post here. Facing a problem where on Windows 10 an Oracle Identity Access Management (IAM) Windows Native Authentication (WNA) protocol fallback to a form-based logon page always fails whenever the Microsoft Online Services Sign-In Assistant (SIA) is installed. Whenever we remove the SIA, the WNA fallback to a form-based logon page always succeeds. This error is reproducible 100% of the time. We have not tested on Windows 8 or Windows 7. I've researched it, and there is not much out there to read about the SIA; it does not look to be configurable on the client end. Really want to avoid changing up code on the IAM WNA side.
Anyone out there seen this before? This is a large enterprise network, using all Windows 10 computers, which has both Oracle IAM running for some applications as well as Microsoft Windows 2008 R2 Active Directory, to which all the Windows 10 computers are joined. We are also standardized with Office 2016 with all back-end servers supporting Office apps such as Outlook, Lync, etc. in the cloud (Office 365).
Please let me know if I need to show the Oracle IAM/WNA SSO fallback code.

The Microsoft Online Services Sign-In Assistant is not configurable. But, if all your computers are running Office 2016 you do not need it anyway and it can be safely uninstalled, which as you said will make the fallback to form-based logon page work. If you were running Office 2013 you would need it however. Office 2016 apps such as Outlook and Lync can go direct with ADFS whereas previous versions could not do this. I don't have a URL reference for you, this is based on my experience.

Related

Dependent objects for New-Object -ComObject Word.Application

We created multiple powershell scripts that read from word document and extract required information.
Locally on laptop all works fine, but when we deployed on production server.... they dont work.
We run powershell scripts through asp.net web app... that's where any powershell scripts that refers to WORD.APPLICATION are not working
Components we deployed on production server:
operating system: Windows Server 2012
Powershell: Version 5
MsOffice 2010 installed
Asp.net 4.5 all components installed
We have created web application in ASP.NET 4.5 Core where user upload documents and based on certain criteria documents will be searched for specific keyterms. if keyterms found, values will be displayed.
Asp.net invokes powershell script which has all document library code to search through. Everything gets executed in PS script, except where WORD-APPLICATION code is referred.
Has anyone faced any issues while deploying them on server?
Required reading:
https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office
All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.
...
Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).
As you can see, the scenario you're trying is officially unsupported, and license wise very expensive, as you officially require an Office license for each user invoking your functionality or for whom you're invoking the functionality.
There is an official Open XML SDK, which will allow server-side processing of the XML-based office documents:
https://learn.microsoft.com/en-us/office/open-xml/word-processing
If that isn't enough, there are a number of 3rd party libraries that provide server-side execution and don't require office licensing, some commercial, some open source:
Aspose: https://www.aspose.com/
NPIO: https://github.com/dotnetcore/NPOI
There are ways to get your code working on the server from an ASP.NET Application. They are officially unsupported, they open up your server to a number of extra security issues, they are very expensive from a licensing perspective and there is no guarantee they will remain working.

CRM 2016 On premise - Can not connect to CRM with Plugin Registration In IFD Mode

I have Microsoft Dynamics CRM 2016 On Premise and IFD Enabled On it.
In this situation I can not connect plugin Registration to CRM. Even I can not connect with XRMtoolbox.
My problem is what is Home Realm URL?
Unable to Login to Dynamics CRM
An Error occurred while processing the login request.
Try removing all your 3rd party plugins except the plugging registration tool.
Also there is a plugin registration tool from Microsoft in the CRM SDK download that you can use as well.
Do yourself a favor and download the CRM 2011 SDK. In the bin folder is the plug-in registration tool. The new version released in 2013+ is complete garbage with bugs that Microsoft Support is not interested in fixing.
That said, I don't think you can "Use Default Credentials" with IFD. For the server you should just put organizationName.domainname.tld. For user name use your UPN or domain\username. Don't use both the domain and user name fields unless you're using integrated authentication.
The Problem is In adfs Endpoints. After you Install IFD on CRM You want a Important Endpoint That Named "Mex".
For Solve The Problem First go to ADFS Management and go to endpoints and Click on adfs/services/trust/Mex and click on Enable and Enable on proxy for this Endpoint. after that reset the iis and adfs service.
Then You can Browse that enpoint with https://service.contoso.com/adfs/services/trust/mex.
if you See the Metadata Xml Document Now You Can Connect With Any Tool Like Portal, Plugin Registration, Xrmtoolbox, etc.
but If you Don't see this metadata use this Command in Power shell to Change The Adfs Port.
Set-ADFSProperties –nettcpport: 809
i Choose 809 for My Port And You Can choose any port you want Except 443 or 80 or 90, Then like before Restart The IIS and Restart ADFS Service and then you Can see metadata And You Can Connect With Any Application to CRM 2016 On Premise IFD Mode.
At The End Of this Answer You can See My Metadata Page And My Connected Plugin Registration Tool Pictures.
If You Have Any Question You Can Ask it From Me.

Windev Software on saas

Hello I don't know very much about the saas system, could you please tell me if a HR software made in windev could easily be deployed as a saas ? The problem is that it would cost a lot to deploy it, because each time a client is connected at the same time, it costs 150 euros (under windows licence). Could you please tell me more about the remote app ? And another problem is that when a client would like to print something, it opens a widows window which permits access to the network, and it is not secured. Is the only possibility to make all the windev software as a web software ? Thanks !
If you don't want to buy Windows licences for each computer, you can :
Generate a java application and run it on Linux, with some limitations
Transform you application in a web app and run it on a web server, with some limitation and some more code
Install your application on a Windows remote server and connect to it with Remote Desktop (a Windows application), but you need licences for connecting you to the server
For me, the printing problem is not a security breach.

Word not connecting to WebDAV server

I'm currently implementing the Class 2 WebDAV server on my company's MVC / noSQL web app. I'm developing it locally on my machine using visual studio 2013, IIS 8.5, Windows 8.1 and word 365. The documents are stored in the noSQL database.
I've managed to get it working in the past, however recently word refuses to connect to the WebDAV server. When I click the document link it open word and the following error appears:
{ correct web address} cannot connect to server.
I have used your built in logging tool and fiddler to see if any requests are made to the server and there are none.
Are there any steps or suggestion you can make to help me debug this problem.
After reading the documentation a few times and trial and error I found that word was caching in the registry. I followed the instructions and rebuilt my project and it seems to have worked.
http://www.webdavsystem.com/server/documentation/ms_office_read_only
Clear Microsoft Office WebDAV cache in registry. Microsoft Office reads WebDAV server options when connecting to server first time and stores them for later use. If your server settings has changed during development (or you just fixed some server issues) you may need to delete this settings. The Microsoft Office WebDAV cache is stored under the key:
HKEY_CURRENT_USER\Software\Microsoft\Office\\Common\Internet\Server Cache\
To clear cache just delete all keys under this key. In a development environment we suggest always clearing the cache if your WebDAV server class has changed or after authentication scheme has changed. As an alternative to deleting cache, you can just reconfigure your server to run on a different port.
Note that in production environment usually you do not need to clear this cache or change port as soon as you server settings do not change often while Microsoft Office will re-request server options after some time.
As soon as your code worked in the past and now stopped working I guess that the trial period, which is 1 month, of IT Hit WebDAV Ajax Library has ended. Are there any errors in the web browser console? To start a new trial period just redownload it here.

Microsoft CRM 2011 IFD vs Windows Auth

Can someone explain to me why one would use IFD (Internet Facing Deployment) to access Microsoft CRM vs. just using Windows Authentication? They seem equivalent to me in their features. Not sure of the benefits of IFD over Windows auth however.
Thanks!
Take a look at this previous answer for some discussion on this topic: Exposed onsite vs IFD deployments for MS Dynamics CRM
I would say from my standpoint the biggest issue with using Windows Auth over the internet for CRM is the issue of Outlook integration. The second point I would make is that Windows Auth can present issues to people accessing CRM from a non-domain computer when outside the domain - i.e., their home computer. Not always but I have seen issues pop-up (not very often) that are avoided in a forms based configuration.
As a reminder in 2011 the IFD feature has been changed signficantly so that you must use Active Directory Federation Service which is claims-based. I recommend reading over http://blogs.msdn.com/b/crm/archive/2011/01/13/configuring-ifd-with-microsoft-dynamics-crm-2011.aspx and watching the video at http://www.youtube.com/watch?v=ZD5qaa-G99E.
You can certainly go with Windows Auth but if you are willing to put in the extra work go with the Internet Facing setups for a more robust and better supported install.
I want to add to privious answer.
Integrating Outlook client from outside the domain can be done by reseting windows credential in the control panel from time to time.
another complication is SharePoint integration which can't be used outside the domain with SSO.
If you do use IFD, I recommand on this blog:
http://dynamics.co.il/configuring-crm-2011-ifd