Hi, I am new to openHistorian, so bear with me.
In our current setup, we have a workstation desktop with openHistorian that is completely functional with PMUs actively connected and archiving with SQLite.
I am trying to access openHistorian on a separate desktop, but when using Integrated Windows Authentication login through the web service (localhost:8180), the following error pops up.
" Current identity unavailable, cannot attempt pass-through authentication - check database configuration."
Also, when attempting to open openHistorian Manager, access is denied with the following message.
" Error loading security provider: Failed to load a valid security context - no application roles were found for node ID ‘8736f6c7-ad41-4b43-b4f6-e68e0d4ad20’, verify the node ID in the config file ‘C:\Program Files\openHistorian\openHistorianManager.exe.Config’. Cannot proceed with user authentication."
Looking for some insights on these issues. Thanks in advance.
Mike
You should be able to access the web interface from a separate system, localhost simply accesses local system, e.g., 127.0.0.1. If you know the name or IP of the computer name hosting openHistorian, you can access it from another computer. For example, if your system hosting openHistorian had an IP of 192.168.1.17, you could access this from another computer on the same network using a URL like so:
http://192.168.1.17:8180/
However, this would require authentication. If you are only using local accounts, that is your network does not use Active Directory, then you would need to add a database user using the localhost interface on the host machine before trying to authenticate, see Settings > Users from the main menu on the Web UI. Make sure to uncheck “Use Integrated Windows Authentication” to use a database user.
Technically, you should still be able to authenticate using a local user account from the remote system as well by unchecking “Use Integrated Windows Authentication” and entering the credentials like so:
UserName: .\yourusername
Password: yourpassword
Where yourusername is the user name you login with on the host system, and yourpassword is the password. The key is the .\ prefix on the user name, this is domain\username format, but in this case a . for domain name means just use the local account.
Hope that helps.
Thanks,
Ritchie
Also, it occurs to me that you may have been talking about using the openHistorian UI Manager application (not web UI) from a remote system. In this case, you would need to run the “Configuration Setup Utility” from the openHistorian instance installed on the remote system. Note that in this case I would choose only to install the manager and associated tools, but not the service components.
The problem, however, will be that SQLite is a “file” based database, and doesn’t necessarily like to share with others. You would first need to create a share on the host system that contained the SQLite database, then map a drive to the share on the remote system, then use that mapped drive path as the path to the SQLite database to use for configuration. Not an ideal scenario.
Your best bet would be to use a real-database in this case, e.g., SQL Server (free express version is fine), or PostgreSQL, for example.
You could then “upgrade” from your SQLite database to the real-database, using Configuration Setup Utility, connecting openHistorian to said real-database on host system in the process. Then you could point your openHistorian UI Manager to same database on the remote system, also using Configuration Setup Utility, but on remote system.
Anyway, authentication issues still exist here, but using Active Directory or database user accounts to authenticate with openHistorian would be recommended…
Much easier to only deal with web UI - however - not “all” functionality yet exists in web UI - so it’s a dilemma.
Hope that helps some - unfortunately no simple answers.
Thanks,
Ritchie
Hi Ritchie,
Thanks for your response. Honestly, my main goal is to be able to access the openHistorian web UI from a separate computer no, and potentially looking into the UI Manager application in the future.
Following your advice from the first post, we have already added additional database users in the localhost interface on the host machine. Using the IP address of the host workstation followed by “:8180” resulted in a timeout response. Additionally, unchecking the “Use Integrated Windows Authentication” box and adding the .\ prefix to my username and regular password resulted in the error:
" Login attempt failed. Bad Request (400)"
To be clear, I can use Integrated Windows Authentication on the host computer just fine. It is only with other workstations this error occurs. Are there any other permissions preventing the login request with the Web UI?
Thanks,
Mike
For database users, do not use the .\ prefix - that is only for local users when "Use Windows Integrated Authentication " is not checked.