I would to modify (enable and set value) of a Machine Group Policy with PowerShell. I understood this kind of Policy is based on Registry. That's why I tried to add my value with Set-ItemPropertycommand.
The new value is correctly set in registry but gpedit doesn't see it.
I tried to use GroupPolicy commands but I don't see how address the Local Group Policy because I don't reach to get a correct GUID.
The key I want to chang is this one: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
I think I miss something but I don't know what. An Idea ?
Thanks
The answer you are looking for can be found at https://superuser.com/questions/1192405/why-gpedit-and-the-corresponding-registry-entries-are-not-synchronized
Quoted from Wes
Since the changes you make in the group policy editor affect what you see in the registry, it's perfectly logical to assume that the reverse is also true. However, it doesn't work that way.
Local group policy settings (which is what I believe you are referring to in your post) are stored in registry.pol files located in C:\Windows\system32\GroupPolicy. These files overwrite the corresponding keys in the registry every time the system performs a group policy refresh. The editor never actually reads the registry to see what settings it contains.
A group policy refresh is triggered whenever one of the following events occurs:
At a regularly scheduled refresh interval (every 90 minutes by default)
A user logon or logoff event (user policy only)
A computer reboot (computer policy only)
A manually triggered refresh via gpupdate
A policy refresh command issued by an admin from the domain controller (if the computer is domain-joined).
It's important to remember that if the computer is domain-joined, domain policies will be applied after the local group policy files are processed (meaning that some settings may get overwritten by domain policy). You will not be able to see domain policies in the local group policy editor.
(Skip to the bottom for the TLDR version.)
OK - so I have searched (really!) and all other UAC articles I have found seem to center on enabling, disabling, detecting or hiding UAC. My issue is not one of those, so here goes:
My user used to have the standard dual-token setup where I was in the Administrators group and the UAC's Consent UI would just ask me if I wanted to proceed. Now, we have separate administrative-level accounts that we need to use, and I have to authenticate with this new user. The problem I am having is that previously, starting an app as Administrator just elevated my current user, where now if I use the credentials of the new administrative user, whatever I am running runs AS that new user.
As an example, previously elevating CMD and typing whoami into the command prompt used to return my normal/current user, where it now returns the new administrative user.
This has serious negative consequences - since this is a new user, and an Administrative-level one, if any files are created using this new user, my normal user cannot write to or delete them unless I manually adjust permissions and ownership. If I use my development environment under the new account (e.g. I need to debug a service or work with a driver) and rebuild something, I end up with a bunch of files that I cannot manipulate unless I am an administrator. Likewise if I add a file while running as this new account - my SCM tool will not be able to update that file later unless it also runs under this new administrative account.
Also, Since a profile is associated with this user, things run under a completely different environment (different %USERNAME%, %USERPROFILE%, %LOCALAPPDATA%, etc.)
Installing an application will also work incorrectly if it is installed just for the current user (e.g. the "Just Me" option), instead of for all users. Things that are licensed to/in my normal user account also fail to function if run under the new account, because things are running as that new user.
The ripple effects of this change are getting larger and larger the more I work with it. So...
[TLDR] Is there a way to get temporary elevation of the current user without that user having the normal dual-token setup you get from being in the Administrative group? Or are you stuck with the impersonation behavior?
I am querying a LDAP and setting variables for mail and displayName. I also need to get account is disable or active. Which property should I need to pull for this?
If using Active Directory the attribute you are interested in is userAccountControl which is a bit mask. Here are the possible values... http://support.microsoft.com/kb/305144/
There is no standard attribute though and it will vary by product and sometimes applications that use the directory server as a repository.
We have auto unlock after 5min via GPO enabled on our network. With this setting, the userAccountControl field remains unchanged until the user logs in. So we have currently no way to find out if a user is still logged or not by querying LDAP.
I have an application that makes use of the EWS Managed API 1.2. Our admins of our Exchange Servers have been good enough to set us up with a mailbox assigned to our service account. All is dandy in connecting and doing the basic functions. The issue we have is that by policy they will not check the box for the password to never expire. Consequently we have to go through the effort in a manual process today to reset the password.
Our desire is to automate this password change so our application doesn't suffer any undo separation anxiety and so we don't have to suffer the burden of paperwork and co-ordination to have the password changed. Is there a way to change the password in an automated fashion?
EWS? SOAP? Powershell? ?????
There could be other ways however you can create a scheduler task using Powershell script to run every 15 days and updating the password:
Set-Mailbox user_name#user_domain.com -Password (ConvertTo-SecureString -String 'new_password' -AsPlainText -Force)
Once Powershell task is scheduled, it will run depend on setting and update the password to your account. You can also generate unique password string based on month or week pattern, or some other logic so don't need to remember and it will be different then the previous.
You could make a simple ADSI call to AD and invoke ChangePassword to do this as well.
in my ruby script I need to pass user name and
password as a plain text in a form in order to log in. Both user name and password are currently stored in my script.
I have no control over the server I log in from the script. The script is localy working fine and in the future I want to move to onto my
webhosting provider and run it from there (I have ssh access)
using cron. Is there any way/method how to
protect the password in case somebody gets access to this script by any chance?
The more I think about this, the more I think you must trust your hosting service. I would make sure the hosting service has "skin in the game": That is, that they host enough "high profile" accounts that being found untrustworthy would be very costly to them (in lost accounts and sales).
And whether or not you think the hosting service is trustworthy, you ought have a plan in case the target account is compromised. Who will you notify, how will you get that account deactivated, etc.
The only technological solution I can think of--you log on manually, capture the cookie, and provide that cookie to the script--protects the password, but presumably a hostile host could use that cookie to do any damage he wanted on the target system using whatever privileges are attached to that cookie, including changing your password. So it's no solution at all.
Oh, speaking of privileges: Can the task you need to automate be accomplished with a target account that has lowered privileges, such as a read-only account, or one that cannot make any changes to its profile? Having only your low-privilege credentials on the hosting service would lower your risk (or "exposure," as the polysyllabic crowd likes to say).
Prior answer, found to be unworkable, below the line.
You can encrypt the user id and password using yet another password. In order to run, the script has to be provided with it's password. It uses that password to decrypt the web service's user name and password. Make sure that the script's password doesn't get stored anywhere, but only held in memory and only for long enough to decrypt the ultimate user id and password.
If it really matters, make sure your connection to run the script is crypto (ssh, ssl, etc.), and make sure the script only uses https to log on.
That doesn't make you invulnerable to someone with root privileges on the box (at some point, the plaintext user-id and password will be in memory, and therefore vulnerable), but it does make it take more work for them to be able to get the user-id/password.
Updated: The requirement that this be automated makes the above solution no good.
If an automated script needs to run something with a password, then you either have to have it readable by the script (which opens up the possibility of someone else reading it) or else not provide it in automation.
The trick is to bypass the "Automation" part by having a one time startup: run the script as a small continual process that will wake up periodically and run. Have the process ask for the password on startup or via some other kind of API request (not on the command line!).
If the server reboots, the password is lost until you log in and enter the password again. This way, the password is only in memory, not on the file system.
You might want a cron job to check on the process and alert you if it is not running.
If you need to pass the password onwards to a form that you presumably can't alter to use a more secure scheme, there's little you can do besides obfuscate the password so that it's not immediately obvious. However, anyone with access to the script itself can simply find where it is passed to to the form and insert a command to print the password there — it needs to be “decrypted” at that point for you to pass it on, no matter what.
To protect it from non-programmers, you could XOR it with something or rotate the letters by some amount, but I wouldn't spend too much time on this as it will be futile against pretty much anyone with a rudimentary understanding of programming. Instead, protect the script itself from other users (set file access rights properly, don't put it in a web-visible directory, etc). And if you do not trust the server's administration, do not upload it there!
You should store a hashed version of the password in your database. A hash is a one way encryption, so it is impossible to use logic to guess the password from the hashed password.
Create a method to hash the password, and do something like this:
require "digest/sha1"
class User
attr_accessor :password
def initialize(password)
#password = hash_password(password)
end
def hash_password(password)
Digest::SHA1.hexdigest(password)
end
def valid_password?(password)
#password == hash_password(password)
end
end
u = User.new("12345")
p u.password # => "8cb2237d0679ca88db6464eac60da96345513964"
p u.valid_password?("not valid") # => false
p u.valid_password?("12345") # => true
When you get the plain text password from the form, you pass it to your valid_password? method. This will do the same one-way encryption as it did when the password was stored. So the one way encrypted passwords are compared. This means that you never store a reference to the actual password anywhere, which is a big win.