I've recently stumble across this problem but cannot fins a reason for this and a workaround.
I've logged on with my domain admin account on a server (Windows Server 2008 R2) and started a service that were set to start manually. After wards when another user with a domain account logged on and had a look at the service as were experiencing problems it showed that the service were in the stopped state although in my session which were still open it showed that it started.
He started the service and everything work after that.
Can anyone shed some light on this for me? And on what to do rectify this or have a workaround for this?
Appreciate you comments and suggestions.
Your service does not to answer correctly to the SCM with SERVICE_CONTROL_INTERROGATE and it span another process with the StartServiceCtrlDispatcher(DispatchTable).
We can't do anything there unless you patch your application or contact your software vendor.
Related
A Weblogic server got hacked and the problem is now removed.
I am looking through the infected VM's now in a sandbox and want to see what if any data was accessed on the application servers.
the app servers were getting hammered with ssh requests and so we identified the infected VM's as the web logic VMS, we did not have http logging on. Is there any way to Identify if any PII was Compromised?
Looked through secure logs on weblogic as well as looked through the PIA logs
I am not sure how to identify what if any data was accessed
I would like to find out what went out of our network and info or data
what should I be looking for
is there anything I can learn from looking at the weblogic servers running on red hat?
I would want to believe that SSH was not the only service being hammered, and that was a large attempt to make eyes be on Auth logging whilst an attempt on other services is made.
Do you have a Time frame that you are working with?
Have the OS logs been checked for that time frame?
.bash_history been checked? env variables? /etc/pass* for added users? aliases? reverse shells open on the network connections? New users created on services running on that particular host?
Was WebLogic the only service running on this publicly available host?
What other services and ports were available?
Was this due to an older version of Weblogic or another service, application, plugin?
Create yourself an excel spreadsheet and start a timeline.
Look at all the OS level logging possible and start to make note of anything that looks suspicious, to then follow that breadcrumb to exhaustion.
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.
I have a very weird problem.
We have a Hyper-V failover cluster, where some guest VMs start to show specific problems after a live migration.
In each case, the live migration mostly works, but after it has been migrated, we can't log into some software (our product WinGate) any more. The SSPI handshake succeeds, we can RDP to the image, so it's not networking.
But ADSI fails to open a search object to retrieve a user object, and gives error 8007203A.
Since networking is working, SSPI is working, obviously domain connectivity is working to some degree, but the ADSI failure is very perplexing.
Has anyone else seen this? I feel it's most likely a bug in Windows, but we have been seeing this for over 18 months now - since we set up the cluster.
P.s. all hosts and VMs are 2k12R2 fully patched.
P.p.s. all VM MACs are fixed.
OK, looks like I found the answer.
Problem is NLA reclassified the domain network adapter after a live migrate, and set it to an unidentified network. This then kicked in the firewall to block ADSI.
thanks to this blog I was able to force NLA to view the adapter as a domain adapter (by adding a domain DNS suffix to the adapter), and the problem is solved. Hope this helps someone else!
we have LDAP Windows Server 2003 R2. It was working fine till now. The problem is that sometimes we cannot access the network based on LDAP authentication. For example:
1) got to \\192.168.1.5
2) enter cridentials
3) It is OK
At some point of time (random) we are not able to access \192.168.1.5
If we reenter the cridentials it will be fine. It also happens with Windows services which log on with LDAP users. We have to enter the service cridentials each time the service is restarted.
So, do you think that the problem can be something with LDAP authentication cache? What else can be wrong. We are experiencing this problem for 2-3 months and we cannot figure it out.
10x
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.