Client Support
Showing results for 
Search instead for 
Do you mean 

Providing access to external users via rich client?

SOLVED
Go to Solution
Valued Contributor

Providing access to external users via rich client?

[ Edited ]

We have a web client installation that partially works, but there is some kind of problem with Web Client in 7.3.4.5739 that can prevent search results from being returned, the web gets stuck with a "loading" message.  In short, this has happened on multiple installations of Web Client in this version of Trim, but did not and still does not happen with our multiple installations of Web Client on Trim 7.1.  We have a ticket ongoing with HP.

 

Besides that problem, which is enough to ensure we can't rely on it at this time to give other external State employees access to our Trim dataset, some of the external users not affected by this bug are not satisfied with the features as a whole of the web client compared to those of the rich client.

 

We currently have some contractors that access Trim by connecting to our network by VPN and running the client with an account on their end that has the same user name and password as an account on our domain, and that account is tied to a location we set up for the contractors in Trim.  They are able to connect to one of our regional servers this way, which is a Windows domain controller, but cannot connect to the Trim server in our central office, presumably because of the stricter security settings on the CO server.  The fact that the contractor can connect to Trim at all this way proves it isn't necessary to set up a trust to another domain or even to install a workgroup server on the external users' network, so that is definitely my preference.

 

The security differences between the domain controller and the member server are numerous and if possible I'd like to provide the external State employees access to the CO server if I can minimize the security reductions necessary to do so.  Could anybody specify which security settings would need to be changed to allow this type of authentication?  I would greatly appreciate the help.  I can open a support ticket if necessary, but I figure there are plenty of Trim administrators that have needed to get similarly creative.  Thank you in advance for any assistance you can offer.

6 REPLIES
HPE Expert

Re: Providing access to external users via rich client?

If you want to go across different domains and they are not trusted, have a look over this and see if you would be able to implement.

 

http://support.openview.hp.com/selfsolve/document/KM1452019

**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Hewlett Packard Enterprise**
Valued Contributor

Re: Providing access to external users via rich client?

[ Edited ]

The method proposed in that document seems pretty hacky and less secure than what we're trying to do.  Our documented experience so far shows that setting up the workgroup server in the other domain and providing their network with direct access to our database and document store isn't necessary.  This is a Windows authentication issue, and I'm comparing group policy settings between the CO server and the regional server now to see if I can pinpoint the exact setting(s) I need to apply, but it's slow going.

Valued Contributor

Re: Providing access to external users via rich client?

We've made some progress on this and although we haven't heard back from the external users yet, internal testing indicates it would succeed.  Here's how the setup works:

 

1.  Create a domain account for the external user and tie it to a user location in your Trim dataset.  The external user has to create an account with the exact same name and password on their system.  It probably doesn't matter if it's a domain or a local account.

2.  Create an identical, LOCAL account on the Workgroup server the external user will be connecting to.  If the server in question happens to be a domain controller you can skip this step because domain controllers have no local account scope.

3.  Have the external user run Trim as the account from step 1 and try to connect to the dataset.

 

I think the reason this was working when connecting to a workgroup server hosted by a domain controller is because domain controllers cannot have local accounts defined, so this "pass-through" NTLM authentication as it's called works differently than on a normal member server, which can have local accounts.  For this reason, I imagine what was happening was that the external user's pass through authentication would reach the workgroup server, which would try to match it with a local account instead of the domain account, and since no such account existed, the process would fail.  By creating the local account on the workgroup server, I assume it's now going more like this:

 

external user's PC -> (pass through authentication) -> workgroup server (matches credentials for a local account) -> (pass through authentication) -> domain controller (no local accounts exist on this server, but matches credentials for a domain account) -> (authentication successful)

 

After I created a matching local account on the workgroup server (a normal member server in the domain), I was able to connect to Trim even though I was running Trim on a server outside of our domain, logged in with a local account.  If this does work for the external staff like it appears it will, this could be a preferable means of providing external rich client access than installing an external workgroup server that doesn't synchronize with the internal ones.  And no direct access to anything more than the workgroup server should be needed by the external users.

Regular Advisor

Re: Providing access to external users via rich client?

[ Edited ]

Why don't just emulate via VPN using Citrix or something similar?. Could give a long answer such as:

- WebClient - Impersonation with different application pools or
- LDAP authentication via VPN and use the one HP TRIM common account
- Develop a custom Wep App authenticating external users and reusing the one HP TRIM account
- Use HP TRIM Guest account

- SharePoint and HP TRIIM

AD and Windows for Work-group authentication are quite different though...be very careful when creating local accounts with the same passwords accross different servers and domains for the sake of handshakes.


**My opinions are my own personal opinions.


kapish.com.au
Valued Contributor

Re: Providing access to external users via rich client?

We have a web client installation, but as mentioned the search function is buggy in this release of Trim and the external users wanted the additional functionality of the rich client.

 

Being part of the State network, they are on a larger isolated network that we are also on.  This is why we didn't require them to use a VPN to connect to us.  I suppose we could require this, but that would probably be inconvenient for them as it would disrupt access to their local network while they were on.

 

Building a web app seems like far too much work to replicate full functionality of the rich client.

 

Our agency would want them to be individually auditable, so having them all share a guest account is probably not something we would pursue.

 

We don't have SharePoint set up.

 

Could you elaborate on what is dangerous with the approach I've suggested?

Valued Contributor

Re: Providing access to external users via rich client?

We've had multiple people access our dataset using the pass through authentication I've described, it seems to work perfectly fine.  In order for drag and drop functionality and MS Office integration to work, we've had them sync their domain password (web conference using an HP Virtual Room, granting them control long enough to type when I initiated the reset of the password for their accounts on our domain) with the accounts on our network so that they can launch Trim normally without having to use "Run as" or having to log into Windows with the separate account just for Trim.  This should also allow the Trim reference file association to work properly.