We have a virtual channel set up using the TsTeleport API.
Following are the parameters of our scenario better -
We are passing a user identity from a client to an RDP session
We have an application on the RDP server that loads the dll, then calls across to the client end to get the information
It works fine only when the client machine is logged in as the built-in domain administrator on the machine we are RDP'ing to
It does not seem to matter what account is used to initiate the Remote Desktop session, but as stated the virtual channel fails to open and is null
There seems to be something going on with the logging-in into the local machine
The client side pipe end dll was registered by that built in domain admin
Any help would be greatly appreciated.
Thanks!
Okay, so as usual, after finally reaching out for help, I've found the solution. Regsvr32 only registered the dll under: "HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Default\AddIns\"
The CLSID needs to be registered for EVERY user before it will work for them. I hope this helps someone else.
Related
I face some strange issue in Silverlight 5 on machine which use window 7.
I have a Silverlight app and after deploying it, it works fine on all user machine but on some of user machine it does not working.
For Example My Username : Test and password is Test.
Now when I use this info to login my app on my machine and also some of other machine then it works fine but when I use same info on other machine (Window 7) it does not work.
I have set mesg for invalid login info in wcf service and return mesg to user. I found that when I use invalid logininfo then it display mesg which I set in wcf method.
I also uninstall old Silverlight and install new on window 7 machine but then also not working.
I think there are something which block to response of wcf service. I am stuck into this issue.
Thanks,
Hitesh
I ran into the similar issue once
When you are talking about the WCF service not working on some machines,
the first thing I would check is the time on that machine(some users set their own time, which is different from the standard time in that particular time zone, WCF service just does not accept the requests from these machines) and then the security level of the WCF service and on the User machine.
Hope this info helps..
I am very new to splunk and trying to set up domain account, but with the custom options the installation rollbacks. I want to receive data from remote system by a universal forwarder. I have provided the same port number as the receiving port which is forward data configurations in remote system. What am I missing here? Can I do so with local system installation?
same question is asked here ...
http://answers.splunk.com/answers/232340/why-am-i-unable-to-set-up-the-domain-account-for-s.html
but there is no answer..
Please help..
The service account must be entered as "domain.name\username" rather than just "username".
I experienced the same problem, having everything configured correctly for running the Universal Forwarder as a service account. However, I failed to enter the service account as "domain.name\username". Just specifying "username" does not work, either when running the installer interactively or silently.
I've got a working WCF service and a working Delphi client. On a normal PC, they work nicely. On a VM that's "Bridged" they work nicely if I log onto the domain (but not if I logon locally to the VM as administrator). If the VM is NATed, the connection attempt times out.
I would love to hear people's thoughts on what could be making such a difference to whether the client can successfully connect to the WCF service. Bear in mind I'm connecting with basicHttpBinding with no security.
The service is setup to use System Account (interact with desktop is NOT checked), and it starts automatically. The service URI doesn't change, the port is open, and can be telnet'd to in all scenarios.
Any ideas or pointers?
Within the VM, open Internet Explorer and verify that you can view the WSDL of the WCF service. If you can't, then your issue is connectivity and has nothing to do with your Delphi code.
Group Policies and Enterprise Security solutions that swap certificates or require certificates to be registered (we're using a UTM called CyberRoam) make a difference.
Also when Virtual Machines join a domain, their ComputerNames are added to a list maintained by the Domain Controller. When the same Virtual Machine is "moved" or "copied", its ComputerName should be changed to avoid DNS resolution issues.
I'm not claiming this as the definitive answer, however it does explain the issues I noticed in this instance.
I'm having a bizarre issue where I'm hitting a WCF service on a remote machine (still in same domain) and it's saying I'm logged in as someone else. On the client side, if I check the Principal.WindowsIdentity.GetCurrent(), it says I'm "COMPANYNAMEHERE\Albert". But when it goes over to the server side, it says I'm "COMPANYNAMEHERE\Albert_Admin". I've had 3 other users test the service and they authenticate fine, it's just me that has this issue.
I've had other devs log onto my machine and they're fine. I've hit other WCF services as my account with the same problem.
The IT folks are stumped, as am I. Anyone out there know what might be causing this?
Turns out something in my local desktop profile (I don't know what) was causing integrated security to resolve me as my _Admin account. I had tested my login on a co-worker's machine and everything worked fine. So my network admin suggested I wipe out my local profile and that seemed to do the trick.
I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)