I have scheduled a task to run a SSIS job using the Task Scheduler (TS). It is configured to run as a User who belongs to the Admin group.
The security is
"Run whether user is logged on or not" is checked
"Dont store password" is checked
"Run with highest preveilage" is unchecked
The scheduled task run ONLY when the user is logged in but when the user logs out the task doest seem to run. I figured "Run whether user is logged on or not" should run the task when the user isnt logged on.
What am I missing?
Follow like this:
Type in secpol.msc /s
Select "Local Policies" in MSC snap in
Select "User Rights Assignment"
Right click on "Log on as batch job" and select Properties
Click "Add User or Group", and include the relevant user.
When I setup tasks to "run whether user is logged on or not", I take this approach:
I create a user on that computer that is a member of no groups. This user is the designated task scheduler user. Open the Local Security Policy and grant that new user "Log on as batch job" permission. If you do not, you'll get this error: "This task requires that the user account specified has Log on as batch job rights." Specific instructions on how to set that permission are here:
http://power-programming.co.uk/post/2010/11/18/Task-Scheduler-This-task-requires-that-the-user-account-specified-has-Log-on-as-batch-job-rights.aspx
Create the task in the Task Scheduler.
Select the "Run whether user is logged on or not" radio button.
Check the "Do not store password" checkbox.
Check the "Run with highest privileges" checkbox.
Assign the task to run under the new user account.
You might find in sig606's solution that the "Add User or Group" is greyed out in Administrative Tools->Local Security Policy->Local Policies->User Right Assignment->Log on as a batch job, Local Security Setting tab. If that's the case, you need to check your Group Policy in AD. A good reference is here.
Basically on your DC, Administrative Tools->Group Policy Management->Computer Configuration->Policies->Windows Setting->Security Settings->Local Policies->User Rights Assignment->Log on as a batch job, edit and add your user there.
Try storing the password. If the user isn't logged in and the password isn't stored there may be no proper authentication. If its a domain user, you can also try creating a local user whose password never expires.
Related
I have set up a form where when someone presses the "Submit" button it initiates a site workflow to create a list item. It all works well when I (full control permissions) do it, but if someone with contribute permissions tries, it fails. I tried adding an impersonation step, but that doesn't seem to be working either. Also, I am trying to record the person who created the list item, and the impersonation step uses my name (workflow author) for "Created By."
Any suggestions as to what I could've possible done wrong, or what I should try to do/add? Thanks in advance...
Simple answer is No.
As you can see the checkboxes in workflow property, you can set the trigger to be
trigger itself when item added or modified.
manually start by users.
For the read-only user, they are not able to click the "start a workflow" button. Also, these users do not have permission to add or modify list item.
You can configure your workflow with "impersonation step". In this way, the workflow will be running under the account of "workflow creator" instead of the user trigger the workflow. However, even you applied "impersonation step", the read-only user still not able to trigger a workflow
For test purpose I added a read-only LDAP look-up via the User Store Management menu at admin, selecting the option:
org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager
After testing, I'm not able to remove this store entry at the Web console doing a "Select All" and selecting the the "Delete" icon. The command confirms deletion of the store, but after a new lookup the entry is still present. It is currently set in a disabled state, as some details are yet missing in the LDAP setup.
It displays a pop-up message like this:
Do you want to delete the selected user stores? Yes
Selected user stores are being deleted. Refresh the page after few seconds to check the new status. OK
After this issue, the dashboard login function stopped working, not accepting local LDAP store registered users. Under admin console access, the local users are still visible.
Please advice how to correct this issue.
A "kill -9 process number" solved the problem reported above and new start of the Identity server removed the web cache error. Yes, it did remove all the persistent entries.
Within my SQL server logs, I am showing a successful login to a database from an account (SERVER\loginname) that I cannot find in either Security > Logins OR Database > Security > Users. This login is being used by a program, so it's not a security compromise, but I cannot for the life of me figure out where it is and I need to find it to make an adjustment. I do remember adding this specific login a while back. Does anyone have any ideas for my brainfart?
if you can try to login with that account, as it is a windows account follow these steps:
from START or from wherever you put the Management studio , hold SHIFT key and right click on management studio icon.
from the menu click "run as a different User"
now login as that account SERVER\loginname
if you successful login , the account has to be in :
select name
from [master].[dbo].[syslogins]
where name ='server\loginname'
or
select suser_sname()-- you will see current login account as a result
if you can't login with that account, read the error and start from there.
hope this helps
Given a set of Amazon credentials (not the username and password, just the API credentials), is there a programmatic way of finding out when that account was created? I am guessing if the user has an EBS volume, S3 object, I could ask the date it was created. Is there a better way?
The easiest way is to check your registered email with subject "Welcome to Amazon Web Services" recieved from "no-reply-aws#amazon.com" email address. This will give the exact date when your account was created.
Similar to the previous comment but with an image. If you go to billing as follows:
Log into the aws console Open the services menu
Search for billing
Then on the right hand side, there is a billing details button
From there you can explore your bills, you can go as back as possible
(which will give you the date)
bill date picker
Yes there is! Open the billing console and then in Datepicker keep on going to the past, until AWS stops you from going. Then you will get the exact date of creation of account.
Login to your root account or any account that has access to billing.
Then go to https://us-east-1.console.aws.amazon.com/billing/rest/v1.0/account
You'll find the registrationDate in epoch format.
In the IAM service there a GetUser command.
That seems to be the most relevant. If that doesn't work, then it might not be possible.
Your AWS account gets activated with the creation of your root user account.
Hence to find out when was your root user created, follow along with the steps below:
Login to your AWS root or IAM account (with appropriate privileges)
Search for IAM service
On the IAM page, Click on the "Credential Report" link on the left hand side menu
Click the "Download Report" button
A CSV report gets downloaded onto your local machine. Open the report using an appropriate spreadsheet tool (like MS Excel, Numbers for mac, etc.) and
Locate the "root user" in the left most "user" column.
Now locate the third column named "user_creation_time" for the "root user" and voila -- there it is what you were looking for...
The easiest way to get this information from the command line would be to use the following command:
aws iam get-user --user-name <user> | grep -i createdate
Replace with the User Name.
Logon to your AWS Account # https://aws.amazon.com
Go to cloudshell prompt on right top or search for it in the seearch box
Excute the below at the prompt
aws iam get-user
Enjoy
Go to (replace /your-user-name):
https://console.aws.amazon.com/iam/home#/users/your-user-name
Look for "Creation time" field:
Screenshot
I've been working on a project to create an FDA part11-compliant e-signed document repository. The mandate is that it use Perforce to track the various revisions of the documents, utilize LDAP (AD) as the authentication/access directory, and re-authenticate the user at the point they submit a changelist.
The first two requirements are in place, but I am having trouble with the last one. I have a script at the "change-submit" trigger which logs out the user - assuming that this would force the client to re-authenticate the user before continuing with the process - but this does not work, at least for the command line client; the user is logged out but the process completes, and the next command attempt from the user is the one that gets denied.
Setting the script to handle the authentication process is not an option as it is run server-side and there is no way to pass a prompt through to the user.
I could of course pass authentication as command-line arguments to the script and then return non-0 to force the process to abort if the credentials are false, but I have not found a way to modify the commands sent for a given action by the p4v GUI, nor again to have the client prompt the user for authentication; and, this would result in the password being displayed as clear text consistently.
Setting the ticket timeout to an extremely short duration would definitely require the user to authenticate prior to submission, but also before any other action.
Has anyone out there dealt with something like this before, or does anyone see an angle of attack that I am missing? Thanks!
Thanks avp for your attempt to help, but my issue was not that the logout wasn't performed, but that the submit that triggered the logout script was concluded anyway.
I basically ended up setting up different groups, one which had all rights except write, and then a group for each authorized user which had write rights, but expired in 90 seconds. I then put all users in the non-write group, and then had a trigger set on login which parsed the password given to determine if it contained a request to join the group with write rights (which was set into a p4v script) and, if the remainder of the passed-in password was correct, assigned them to that group.
I've had it in production for a few months now with no issues.
Well, I have no idea why it did not work for your client, but you can try this:
remove the p4tickets.txt file or remove the necessary line in this file after you logged out.
(After I log out I can see that one line (the line for the client I logged out) is removed from the p4tickets.txt.
Each time I have any problems with logging in/out I remove this file and it helps.