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.
Related
Is there any way we can enforce the password policy changes with the immediate effect i.e enforce the user to change the password while logon if it is not met newly added policy settings.
I heard that something we can do with Powershell WMI Bridge Scripting. I am very much new to it any help on this topic please.
But as per Miscrosoft
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/hh994562(v=ws.10)
the new password policy will come to effect when user changes password manually or age of the policy is over. not immediate.
is there any way we can enforce password change?
You could use PowerShell to check the User must change password at next logon check box for every user.
Set-ADUser -Filter * -ChangePasswordAtLogon:$true
would do just that. But please don't run it without knowing what you're doing!
I have a PowerShell script that runs under its own user account for security purposes. It needs to be able to schedule tasks as part of its operation, and uses the ScheduledTasks module to do so. After seeing this question, I granted the script's account Full Control over %SystemRoot%\System32\Tasks, but Register-ScheduledTask still fails with "Access is denied." I have allowed the script's account to log on as a batch job and as a service.
What permissions/configuration changes are needed to make this work right?
I've discovered that the problem was due to me specifying -RunLevel Highest. Apparently you can't do that with a restricted account. Removing that parameter allows it to work.
I'm trying to create a scheduled task in a Group Policy that runs a script that lives on the domain periodically.
I understand that storing the password in GP is a no no, so avoiding that. However, it seems like there is no way to deploy a scheduled task that can run with access to the network.
I tried the "System" account, that failed with access denied. I also tried using the "Do not store password" setting with a named account, which also prevents network access.
The scripts live in \domain\netlogon land and has full read access to authenticated users.
Is there anyway to accomplish this without having to manually install the task on every server and provide a named service account?
This is a Windows 2012 server domain with about 20 servers.
I ended up getting the "System" account to work correctly.
I am trying to have a windows Admin account automatically login multiple local users on a script. The idea is to run a set of applications (tests) in each user session.
Currently I am able to do so by loggin in remotely (RDC) to each of the individual user accounts. This would be fine if there were just a few of these accounts, but now I have upwards of 30 machines with an average of 6 user accounts each so RDPing to each is extremely time consuming.
Instead, I'd like to be able to login as the Admin, and have some sort of script to automatically login the local users within a group, or just a list of users, so I can start the applications using pstools (the applications require desktop interaction, so a session is required).
I have found that you can only automatically login one user via Windows User Accounts.
Does anyone know of a way to login multiple accounts via command line, or automatically somehow?
Use Invoke-Command to execute commands against a remote computer which also has Powershell, and has WinRM enabled. Invoke-Command can also run non-Powershell commands.
# users stored in csv with "username, password" format
foreach ($user in $userlist) {
Invoke-Command "runas /profile /credentials $creds /user:$user.username /password:$user.password *executable*
}
Use the -asJob parameter to run them as separate jobs, or run them in sequence for simplicity. Remote PSSessions are another possiblilty to consider if you need to run multiple commands. Research storing credentials, encrypted, in a file for repeated use.
This is actually not possible, you cannot log in to multiple accounts in command line. RDC is the only feasible way. May be you can automate the RDC for multiple users using other automation softwares like auto it, WSH scripting or some macro recorders. Which might help resolve some effort in your work.
Use runas to open new cmd. After that start your test, they will use your new credentials.
It can be done by 3rd party tool http://www.logonexpert.com via its command line tool, in such manner:
le.exe /logon user1 pass1 domain1
le.exe /logon user2 pass2 domain1
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.