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.
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'am using open source tools for the first time. I would like to install sensu, All i want to know that is there any method in which i can add my newly provisioned service automatically to the sensu server.
#vineesha We can make this possible when using rabbit mq, please write a script to fetch hostname and Ip address and update client.json and restart rabbitmq server and sensu-client. In the golden image please hard code the IP address of sensu server in rabbitmq.json. When all this is done please set a cron with #reboot and this should be all. When the server is launched it will automatically add to the sensu server.
If you are planning to use automation tools like for example puppet, all you need to do is to ensure that the sense-client is installed and the client config includes the correct RabbitMQ config.
As soon as the client connects to the same RabbitMQ host/cluster it should also pop up in you dashboard e.g. uchiwa.
There is no need to explicitly give the sense-server any information directly.
In the weblogic console, one of the nodes are not showing their health status while admin server and other nodes are showing there health status as "OK".
Is there any issue regarding communication between admin server and managed server or some other reason for this node not showing a health status?
What should be done?
I am able to get the status of managed server by restarting the managed server only.
it seems it is the problem due to unstability of the environment.there was problem with the start argument of the managed server.
Yes, that looks like a communication issue between Admin and Managed server. What you can usually do is:
Restart all. Then start Admin first and wait till its on. Then start the Managed server. Does the problem still persist?
Check that the Managed server is started properly. See that there are no errors in the log file.
Check the logs of the managed server. See if the managed server complains about not being able to connect to Admin, otherwise there should be a log message saying that the connection with the Admin was established.
You can also start Managed server without starting the Admin server, see if the Managed server is trying to contact the Admin server or not.
Check the config.xml file of the Admin and Managed server. Check the node and servers definitions, check their IP addresses, ports, etc.
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. :)