When did I last talk to my Domain Server? - windows

How can my app get a valid "last time connected to domain" timestamp from Windows, even when the app is running offline?
Background:
I am writing an application that is run on multiple client machines throughout my company. All of these client machines are on one of the AD domains implemented by my company. This application needs to take certain measures if the client machine has not communicated with the AD for a period of time.
An example might be that a machine running this app is stolen. After e.g. 4 weeks, the application refuses to work because it detects that the machine has not communicated with its AD domain for 4 weeks.
Note that this must not be tied to a user account because the app might be running as a Local Service account. It the computer-domain relationship that I'm interested in.
I have considered and rejected using WinNT://<domain>/<machine>$,user because it doesn't work while offline. Also, any LDAP://... lookups won't work while offline.
I have also considered and rejected scheduling this query on a dayly basis and storing the timestamp in the registry or a file. This solutions requires too much setup and coding. Besides this value simply MUST be stored locally by Windows.

I don't believe this value is stored on the client machine. It's stored in Active Directory, and you can get a list of inactive machines using the Dsquery tool.
The best option is to have your program do a simple test such as connection to a DC, and then store the timestamp of that action.

IMHO i dont think the client machine would store a timestamp of the last time it communicated with AD. This information is stored in active directory itself (ie. on the DC)
Once a user logs into say a Windows machine the credentials are cached. If that machine is disconnected from the network the credentials will last forever. You can turn this feature off with group policies, so that the machine does not cache any credentials.

Related

Access to a shared folder for an application, but not the user

I have an application (in a pure windows environment) that needs to store sensitive data so that other workstations with the same applications can access that data.
At the moment that's done using a central server with a SMB network share and encrypted files.
All (windows) users that use our application have to have read/write access to one central shared folder and this way data is stored and exchanged.
This configuration has one big drawback: Not only the application but also all users of our application have full access to that shared folder.
Ok, they can't read the sensitive data, as it is encrypted, but - given some criminal energy or stupidity - they can simply open a windows explorer, navigate to that shared folder and delete files there.
I tried but didn't manage to open the SMB-share only for my application - as soon as my application authenticates there, also the current windows user has access.
(I tried using WNetAddConnection2, but as soon as the authentication happened, the connection is opened also for all other programs. And if I don't map the SMB folder to a drive letter, I can not even disconnect the drive again)
Are there possibilities to authenticate only a process or a thread and not the current user for access to a network share?
Or are there performant alternatives to SMB shares? One data record is something between 100 and 900 MB in size. Therefore I need support for random access reading/writing to the files.
Using SFTP and pumping the entire data to the workstation when opening and sending everything back when closing is not an option. That would stress the network and if the application crashes, all changes are lost where when using "normal" access only the data in the network cache is lost.
Any recommendations?
Are there possibilities to authenticate only a process or a thread and not the current user for access to a network share?
No. Windows' security model is based on users, not applications. To apply rights on a per-process basis, you would have to run the application as a given user. To apply rights on a per-thread basis, you would have to impersonate a given user before doing the work, and then revert the impersonation when finished.

Script to run at first logon in OS X to "call home"?

I sell Macs and i'm looking for a way for our security and to combat purchase fraud to have the machines phone home the first time they are booted up to show that machine has been in use at the clients IP address.
Now I know the client might set the computer up at a location other than their home and could spoof their IP (although the potential scammer wouldn't realise this system was in place so wouldn't be expecting to do this) but any system is better than no system.
In terms of privacy we'd put it in our privacy policy but of course we're not looking to collect any information from the user apart from their IP address and the script should delete once its connected to the internet for the first time.
How would users recommend the best way to do it? I have full access to the computers before hand and we already launch a script on first boot of user account to show a welcome and help guide - so we could add simple scripting there, but maybe a helper program which attempts until internet connection is first established, makes contact and deletes itself is best.
And of course we'd need a two pronged approach, a URL or API of some sort on our server that the computer connects to. Ideally the information to send would be the serial number and the IP address of the user, the MAC address could be useful too - as often if fraud has been committed the police will also check to see if the original MAC address of the system has connected via the ISP server logs.
I suppose the final piece of the puzzle would be that our logged data would somehow need to prove it was sent from that computer and not just generated ourselves in a database (eg we haven't just pretended its connected from their IP we've picked up from an e-mail address or something) i'm not sure if there would be any secure legal way to do this?
=============
Edit: Thinking of ways to make it legally binding in terms of presenting the information to the police or the courts I think the receiving server would need to be hosted and maintained by an independent third party whom you had a contract with and didn't allow you any write access to the information what so ever, all you could do is visit a website and pull up the data to pretend the evidence to the police.
(I seem to have been voted down because someone likes committing fraud?)
I have looked into similar solutions for macbooks in the past with little luck. One thing I have found however, if you have a web server, is to create a php page in an obscure hidden directory that will capture the ip address and send an email on access. From here you can create a page specific to each computer with MAC and serial number and set this as safari's homepage in a different tab. So every time someone attempts to access the internet you will be notified.
(This php page can be a simple blank page that just looks like a new tab, or can even display warnings such as "You are being tracked")
You could also create a python script on startup to send the information you are looking for such as ip, mac and serial number back, but again you would need another server setup as a listener.
And lastly, if possible, create a business account in icloud and use Find My Iphone/mac. This is probably the easiest if you can get away with it but unfortunately will not provide you with instant notifications.
-M

steps to securing amazon EC2+EBS

I have just installed a fedora linux AMI on amazon EC2, from the amazon collection. I plan to connect it to EBS storage. Assuming I have done nothing more than the most basic steps, no password changed, nothing extra has been done at this stage other than the above.
Now, from this point, what steps should I take to stop the hackers and secure my instance/EBS?
Actually there is nothing different here from securing any other Linux server.
At some point you need to create your own image (AMI). The reason for doing this is that the changes you will make in an existing AMI will be lost if your instance goes down (which could easily happen as Amazon doesn't guarantee that an instance will stay active indefinitely). Even if you do use EBS for data storage, you will need to do the same mundane tasks configuring the OS every time the instance goes down. You may also want to stop and restart your instance in certain periods or in case of peak traffic start more than one of them.
You can read some instructions for creating your image in the documentation. Regarding security you need to be careful not to expose your certification files and keys. If you fail on doing this, then a cracker could use them to start new instances that will be charged for. Thankfully the process is very safe and you should only pay attention in a couple of points:
Start from an image you trust. Users are allowed to create public images to be used by everyone and they could either by mistake or in purpose have left a security hole in them that could allow someone to steal your identifiers. Starting from an official Amazon AMI, even if it lacks some of the features you require, is always a wise solution.
In the process of creating an image, you will need to upload your certificates in a running instance. Upload them in a location that isn't bundled in the image (/mnt or /tmp). Leaving them in the image is insecure, since you may need to share your image in the future. Even if you are never planning to do so, a cracker could exploit a security fault in the software your using (OS, web server, framework) to gain access in your running instance and steal your credentials.
If you are planning to create a public image, make sure that you leave no trace of your keys/identifies in it (in the command history of the shell for example).
What we did at work is we made sure that servers could be accessed only with a private key, no passwords. We also disabled ping so that anyone out there pinging for servers would be less likely to find ours. Additionally, we blocked port 22 from anything outside our network IP, wit the exception of a few IT personnel who might need access from home on the weekends. All other non-essential ports were blocked.
If you have more than one EC2 instance, I would recommend finding a way to ensure that intercommunication between servers is secure. For instance, you don't want server B to get hacked too just because server A was compromised. There may be a way to block SSH access from one server to another, but I have not personally done this.
What makes securing an EC2 instance more challenging than an in-house server is the lack of your corporate firewall. Instead, you rely solely on the tools Amazon provides you. When our servers were in-house, some weren't even exposed to the Internet and were only accessible within the network because the server just didn't have a public IP address.

Record Windows session to remote website

I have some solutions running on third-party systems, and every so often a customer specific error occurs. Unfortunately, due both to the amount of customer customization and the access difficulties, we are not really able to replicate these (rather trivial) errors. Is there a application, free or paid, that can easily run on a Windows server, record all activity and send back a video to our servers?

How to securely store database credentials for Windows application?

I have a python application designed to run as a service on Linux, and I've been asked to install it on a Windows XP box in an office where there are no Linux machines (for me, this makes it a bizarre and confusing place as I have virtually no experience developing for Windows).
On Linux the application has its own user, and the application and database credential file reside in an encrypted folder accessible only by that user. (I'd like to state that I am not a cryptologist, and that if there are already glaring security errors in this set up I'm very happy to have them pointed out to me!)
How can I achieve an equivalent level of security by similar or different means on a Windows XP machine? That is to say, how can I prevent those who have access to the computer or the disk altering the program or reading the credentials?
A little background: the host windows box is a workstation used every day by users with non-administrative privileges. The secure assets are personal data roughly as sensitive as, for example, a school report. The application is intended to be used by about 10 people who authenticate to the application with individual passwords (stored salted and hashed in the database).
There is a very similar question that received the answer:
on Windows you would store the credentials in the registry in a location protected by an ACL
However, it doesn't touch on the aspect of protecting the program files, and further it seems to assume a higher level of Windows experience than I currently enjoy :) I have no idea how to protect registry items with an ACL, nor how I would then be able to access the protected keys from my program. Simple instructions for a developer in an unfamiliar environment would be greatly appreciated!
Your question is unclear about what your application does and what your security requirements are. I'm going to make some assumptions, and provide an answer based on them. If these assumptions are incorrect, please clarify in a comment and I'll update.
I'm assuming you have an application that:
stores sensitive data in a database stored in a DBMS installed on the workstation
is installed on a shared workstation
each user has their own login (non-admin)
allows different users to log on and interract with their data
user runs applicaiton which connects to a service
service connects with database, delivers data to users
service runs under its own user account
If this is correct, then you shouldn't have much issue.
The service can run under any account, but it would be easy enough to have it run under one of the standards (Local Machine or Network Service). Configure the database so that only this account can access it. In Sql Server, I'd only grant that user account (and admins on the box) login and access rights to the database.
This is the only security you need, if the users aren't admins. Now, when the frontend connects to the service, the user can provide the username/password and the service can authenticate against salted and hashed passwords stored in the database. All this is secure as long as 1) each user has their own login 2) communications are secure (using named pipes or SSL) and 3) no virii or keyloggers are running under an admin's credentials.
You can configure your service as to what account it runs under by running services.msc (or right-clicking on MyComputer and selecting Manage or clicking on Services under the Admin tools menu in Control Panel or probably in a number of different ways).
Bring up the list of services, right click on your app and hit Properties. From there, make it look like this:

Resources