Hello All Three Months ago I had Installed WebFocus 8.2.7 on...

[Naeem Sufi 3]

Hello All

Three Months ago I had Installed WebFocus 8.2.7 on an our SandBox (Win 2016/ wf 8.1.5M ) I resolved all the issues and remediated all reports/dashboards and have it working

Now for our Development environment I have brand new 2019 Win Server

I installed WebFocus 8.2.7 on a new Windows Server 2019 Box as New Install

After installing WF Server and Client software , I made sure all the configuration files are the same between the SandBox Server and these are the same I (Admin) can login and see the everything

But when I use a test user Id I get authentication failure Looking at the logs I see the that When I (as a Admin) login my id is preceded by the domain name but when I login using the test ID , this ID is not Prefixed by Domain After going through all the admin console and wf server screens and comparing all the configuration files , i dont see any issue , they are as I have on the SandBox Server where this test user can login without any issues I even have contacted IBI Support and the person walked through with me with all the screens and did not find any issue , user has access to the windows server and is part of the users on that server/domain We have EXTERNAL security and OpSys (Primary) and LDAP as secondary

I have checked everything running out of options to try

the difference is that SandBox server is Windows 2016 and I used in place upgrade the existing 8.1.5 Version

on 2019 Box its new Install with the repository that I had on the SandBox (Copied to different location for the Dev env)

if anyone here had this issue or know what could be the issue causing Authentication failure , would appreciate if they can share here

Thanks

[David Hall 5]

There is a setting under the security setting in the WFC Admin console

Under each of the zones.

If you are using IIS and LDAP with authentication, and have single signon enabled, go to the JEE option which should be the default and right click edit

You should see something like the following

 

By default the domain name is disabled. So me signing in as corpdavid, becomes david. If you want the domain (Ldap adapter name) name, so the user is corpdavid then uncheck this option.

[Naeem Sufi 3]

Thank you David I will look into that but what I found out is that users who are in windows 2019 Administrators Group are able to login and and those who are not in the administration group are not able to login Our server teams is implementing Hardened Group Policies on these new windows 2019 servers

is there any documentation from IBI as to what privileges a user needs to have on the Operating system to be able to successfully login to WebFocus

Thanks

[Toby Mills]

Hi Naeem,

Sure sounds like youve got something configured differently from one environment to the next. Maybe just not in a normal place to look.

I just did a couple of windows 2019 boxes - one client and 2 WFRSs and it all works just like my 2016 box for me.

But - we dont use OPSYS or LDAP. We use a custom provider.

Since I cant see exactly what to ask you to try, Ill pass along what I think is a useful trace to turn on.

com.ibilog - turn this from INFO to TRACE using the Admin Console / Log Files / Event

 

image.png1188414 42.9 KB

 

If I remember right, this will give you more info about the logon attempt and might give you some new information in your logs folder.

Also - doesnt the WFRS Web Console have a way for you to test logging on via OPSYS or LDAP Maybe you can try to get the user to log on there to see what that looks like.

Is your user supposed to authenticate from OPSYS, or from the secondary LDAP Either way, you might try using the access control provider ahead of the user ID like LDAP/userid when you log on.

I presume you are pointing to the same repository where you already made all your fixes to make 8207 work. Maybe your could try doing an Effective Policy or Group Membership report for the user in question. Perhaps something will pop out there.

Hope some of those give you more to go on.

Let us know how its going.

[Brian Suter]

Since the server is doing the authenticating, the issue is over there. And since your primary is OPSYS and the provider name is not being passed from the client, the server is going to do an opsys credential check. And I assume you are seeing the authenticate failure in your edaprint. A little interested, when do what LDAP to be used

[Naeem Sufi 3]

Thank you Brian and Toby

Yes We are using Opsys as Primary with LDAP as secondary Yes , Toby using the same Repository from the sandBox (Just restored to another location) Some of our Applications require Trusted Connection, IBI recommended solution was to use Opsys (During our fist migration to 8 from 7.611 few years back)

With our Security admins enforcing the Hardened Policy where they dont allow impersonation , as Opsys requires impersonation so it was not authenticating but IBI tech support provided the solution to add

logon_method = network to edaserve.cfg

that resolved the issue

I had configured my SandBox and Dev exactly the same it is just 2019 Windows server they implemented Hardened Policy we had tried reverting to Standard Policy on Windows server it works standard Policy,.no authentication failure but here in the company they are implementing more secure environments

now I have to move to HTTPS:// from HTTP:// for our webfocus environments , we dont have any external users but they want me to use HTTPS , if you have any info on this , please let me know

Thanks for sharing the above information

[Naeem Sufi 3]

During Testing I inactivated the Opsys and used LDAP secured , it let the user in but then our applications that require Trusted Connection did not work so that was not the solution

[Toby Mills]

Hi Naeem

Sounds like youre still trying to iron this out.

Look in the Security manual for Configuring WebFOCUS for SSL.

What do you use for a Web Server (like IIS on windows for example) Are you using Tomcat for the webapp server Both products need to be altered to know where your certificate is located and theyll need some other changes as well. Besides reading our Security manual, there are quite a few good articles on the web for setting up HTTPS for IIS and Tomcat.

WebFOCUS itself doesnt really need any changes that I can remember. The changes are primarily WebServer and AppServer (tomcat).

Heres a couple of paragraphs from the security manual:

 

To activate Secure Socket Layer-based communications, create a self-signed certificate for

Java. You can optionally submit it to a Certificate Authority to establish it as a trusted

certificate. The keytool utility that creates the certificate also modifies the connection type

from open to SSL. Therefore, you must comment out the default Connector Protocol setting in

the Tomcat server.xml file, and ensure that a setting for the new SSL Connector Protocol

appears there instead.

Finally, the establishment of SSL security requires the replacement of the default connections

between WebFOCUS and the internal applications that create graphs or deliver output to Excel

spreadsheets with connections to the JSCOM3 Java-based listener. To implement this change,

you must assign the value Reporting Server JCOM to the Excel Server URL (EXCELSERVURL)

and Graph Server URL (GRAPHSERVURL) settings within the WebFOCUS client.

 

Hope that helps.

[Ernesto Scarpato 2]

Quick question for you. Have you verified/tested the connection from the Reporting server to the LDAP server is working correctly ( From the server console, under Access Control, see if it will authenticate your user, and list the users of an LDAP group)

[Naeem Sufi 3]

Thank You Toby

Yes I will checkout the HTTPS issue This is good information for me to start

Thanks

[Naeem Sufi 3]

Thanks Ernesto

Yes Test the LDAP connection and it list users

the issue was that Opsys does impersonation Hardened Policy (no impersonation allowed) on windows server was not letting users connect (only Windows Administrators Group was passing through)

IBI Support provided this one line of code to add at the end of edaserve.cfg

logon_method = network

That resolved the issue