I am trying to enroll about a 100 systems in Intune. I want the user to be signed in as a standard user. I searched and found the only way to do this will be using AutoPilot. Thats is just not possible, It requires a factory reset device and a hardware hash for each device.
The other way they say is to run a Powershell script. That option won't work because I want only the one microsoft account on the system. Windows needs at least one Admin account.
I simply want the normal user to be a standard account and in case he needs admin privileges I can connect and type in cloud device administrator's credentials to give him access. However, I cannot find anyway to get this done, kind of hard to believe this is so difficult to do. Any suggestions?
Related
What I need to happen is that the user enter his domain/username/password as usual, but also enter an additional token, that I can somehow intercept during the login process, authenticate it, and allow the login or not. So, effectively, the user logs in only if Windows allows it, and this secondary authentication process allows it.
Does Windows provide support for this? Some mechanism to implement this?
All modern versions of Windows (since XP) have varying degrees of native support for two-factor authentication. You aren't very specific in your requirements but if you only need local workstation authentication (meaning that a domain user needs 2FA to log into a specific PC) then you can do this very easily with any of the Yubikey products. Their $20 USB token can be associated with a user on a workstation using their free software and using built in Microsoft controls.
If you want Active Directory domain-level authentication then you are going to need a product like Authlite to authenticate users. Basically, you roll out a simple .MSI to all resources via GPO and you can either centrally enroll users OR users can enroll themselves. Key pairings are stored in Active Directory Application partitions and all works very seamlessly. Works with 32bit or 64bit Windows all the way up to Windows 8/Server 2012. Currently per-user costs for Authlite are $48 total with no recurring costs. Each user would need a USB or NFC token.
Mark Ringo
As we all know,we can use such api as "LockWorkStation()" in "user32.dll" to lock windows.
But how to unlock it?
For example, if i run an app at first, I want the app to unlock windows by itself after 30 second.
How to do it? In another word, if auto-logging in, windows will read the username and password from regedit and then use an api to login by those.
Now i need the api. It must exist, but it seems not to make public.
I can get the app the username and password of the windows.
It seems that there is some Api in WBF.But you know,the resource is too less.
I don't want to send keyboard message to solve the problem,for it is the worst method.
Promoting my comment because it needs more explanation:
You really want to write a GINA (for XP) or a Credential Provider for Windows Vista and beyond.
Fundamentally the Windows authentication model is based on the user providing evidence (identification) that they're authorized to access the computer (either by their credentials or biometric data or smartcard or other information). Once you've been authorized to log onto the computer, Windows allows you access.
When the workstation is locked (for whatever reason - screen saver, user typing in Win-L) the user needs to be re-authenticated.
Typically that's sufficient - the authorization is good for a period of time (determined by the administrator). If (for policy reasons) you need a finer grained control model, you could use your "LockWorkstation" idea to force the user to re-authenticate themselves. You need to be VERY careful about false positives (nothing pisses off users more than being told they're not allowed to use their computer simply because they removed their glasses or combed their hair differently) and how much drain on system resources your app causes.
When the workstation is locked the only way to unlock it is by the user logging in (pressing Alt+Ctrl+Del and entering correct password). This is a security feature that you cannot circumvent using an application API.
Let's say we have an application that has a number of features and each feature as a permission set of users that are allowed to use that feature. The application is designed to be always-on, but at different times during the day we want different users to log on and use it.
Rather than reinvent the wheel and create yet another user account and password system, we'd like to use built-in Windows user accounts (for authentication) and Windows groups (for feature access).
Is it possible to leave the application running but have different users come along and log in and log out of the application without logging out of the Windows session?
There is a mechanism called Impersonation (link points to .NET documentation, but the core Windows APIs provide similar features). It allows you to programmatically run code in a context of a different user than the one currently being logged in. There are, however, other security implications to the model you describe. In particular: how do you protect the rest of the workstation your program is running on?
Well, you could certainly have the application get the user's windows credentials. You could also simply query for group membership without requesting any credentials. More specific information will help with a more specific answer. For instance, what language are you working in?
I've written an application and I'd like to add a registration key/serial number to it (I'm big on minimum inconvinience - ala #4 at this Eric Sink article). My question is about where to store the "activation" once the application has been registered. As I understand it, I have a trade-off between storing the key in a public place, where all users can read it (but which requires admin rights to save there) and storing a per-user activation (but then each user on the computer will have to activate independantly). That gives me two choices:
Some user, with local admin rights, activates the product. The activation is stored in HKLM, in the program files folder, or somewhere else where all users can read it, and the product is activated for all users.
A user (with or without admin rights) activates the product. The activation is stored somewhere user-centric (per-user app.config, HKCU, etc). The plus is that the user doesn't have to be an admin. The downside is that if there are 6 users who use the computer, each has to activate the product. They can each re-use the same serial, but they still have to enter it.
Is this really the trade-off? If it is, what have others done? As a developer, I'm used to people being a local admin, but in the real-world, I don't expect many of my corporate users to be local admins, which makes me lean towards option 2. Are computers not shared often enough that I shouldn't be concerned?
Again, I'm not asking about how to physically register a computer - I'm not worried about it. I'm only going to checksum the key provided and give the go-ahead, as I want to be as non-invasive as possible.
I would recommend a solution that does not require admin rights. Lots of users, especially in shared environments, won't have those rights and won't be able to find anyone with them conveniently.
Also, going forward a few years, I think it will be getting increasingly unusual to have admin rights on the computer you are using, as the security situation improves.
Registry seems to be an okay solution for business software. At least at where I used to work, regular user will not be a local computer administrator, so each installation will require local administrator account. This is a good thing since it will lessen the headache of your support staff from people installing just about everything in your business computing environment. The trade off is of course, user will be pissed that they can't install stuff or have to contact support to do it, but hey... :)
Other stuffs:
USB / other type of dongle (ala old
3DMax)
plain old text file (ala
Garmin GPS software on mobile device)
Encode them / rewrite the key into
your binary or part of your binary
(did this trick back in th old DOS
days)
Store them in your own db via web (ala EverQuest / other MMORPG games)
Local key db (ala MathLab I think)
How about using the isolated storrage for you application?
You will have the ability to store this information on a mashiene level for your registration, and the configuration changes can be persisted on a user level.
We save our activation code to the registry for the current user (HKCU) we have had very little problems with it. Our customers run on everything from home computers to thin clients on cooperate networks.
If your software will be used in schools or other educational environments you need to provide some other method. It could be as simple as a separate registration application which will save to the activation for all users. Your software would have to do two registry lookups but that is a small price to pay.
In general, most computers are used by a single user (or multiple people still using the same user account). So a user based storage will work most of the time anyway.
However it's not either/or. There are folder locations that are writable by all users - such as the ProgramData folder. The key is to make the file readable/writable by Everyone so that you can verify the content regardless of the user.
DeployLX Licensing does this for non-secure license data so that it can be used by multiple users without an admin explicitly granting permission.
You should be consistent. If administrator rights were required to install the program, it's not out of line to require administrator rights to register it. Likewise if you somehow managed to install it without administrator rights then register it without too.
If you install and register in one step this won't be an issue.
Let me state first: I know that any user that wants to run a program (or even log in), has to have access to (probably at least) the Windows system directories and the shared libraries in %ProgramFiles%, but I'd like to be able to access Skype, for example, by running it with an unprivileged user and make sure that it can't access any unnecessary files.
I fear that the only way to do this would be to identify all of the gazillion directories where I store files that I don't want this user to access and then create a new user group that can access these directories, or run Skype and Azureus in a VM.
Is there a better way?
Normally, accounts are members of the Users group at least, which does have access to many things. You could make the account a member of no groups, or the Guests group which is very restrictive.
The real issue is that the program's token (an internal security object that keeps track of what security identities a running process has) will contain the Everyone and Authenticated Users groups, which also have read access to lots of stuff. There is no way to create an account without those groups. You could remove the access that Everyone and Authenticated Users groups have to most everything, but it would be a lot of work to track all those down.
I would say that creating a standard user or guest access account for untrusted programs would be plenty secure enough. To support self-updates and to keep related files in the same place, I suggest you install those programs directly in the profile of the user account they will be running as, e.g. C:\Documents and Settings\skype\Program Files\Skype
If you want to get really fancy, you can use a restricted token to either make the Everyone, Authenticated Users, etc. groups deny only (so they can't grant any access) or create a Restricted SID list. This will be difficult to implement because there are global objects that programs will expect to access that the Everyone group has access to, which is normally a safe choice.
See CreateRestrictedToken Function.
There is also an open-source command line program I created a program for creating restricted tokens and job objects on the fly for that purpose: UlimitNT
Maybe sudown is a solution. It's a sudo-similar (as known from Linux) approach to running as unprivileged user, but having the possibility to promote to an administrative account (with password) when needed.
I suppose you could lock down the machine so the user can solely log on, not even start skype with his rights, but start skype by "run as" with sudown.
Besides using a VM you could look into using a Sandbox. Look at Sandboxie fox an example.
simply use acl apis (samples in msdn)