I am trying to create a application using innoscript. I need to create/edit registry information values in HKLM. Hence I need admin privileges to install the application.
However, if a non admin user try to install the application, innoscript require admin user password, once they enter the admin user password, whenever I query the registry in installation script (say, HKCU), it retrieves information from the admin user. But I would like to get information from the currently logged in user. As a result, program installed under the admin user location instead of current logon user account.
Is there a way to get current logon user user and user app data location from innoscript, when the application is started with Run as administrator or prompted admin user.
Awaiting your update.
Thanks,
The installer is not supposed to read or modify any per-user state (including HKCU) during a per-machine installation (and there is no way to do so reliably). You should instead make the application itself do this on first run (by trying to read the appropriate location and assuming default values if they were not found).
Remember, an application is installed once, but can then be run by several different users. This behaviour is essential.
An easy workaround is to move your logic to an executable instead of Pascal script. Then you can call this executable in [Run] section,
http://www.jrsoftware.org/ishelp/index.php?topic=runsection
Remember to mark the Run item as runasoriginaluser.
Related
I am coding a Rest API with express and I have a middleware to check if a user is admin or not. However, I wonder how companies assign a new user as an admin? Do they edit the database record and change the role there?. I guess that one admin could make another user admin but how is the first admin created? Is there a way to do it in the frontend?
If it's a software platform (meaning one web address and database for all users of your app) then the first admin user is typically created by running commands on the server command line console to create the right record. Or perhaps by a setup script that is run once. This creates the first admin user, and then that user logs in and creates more admin users via the UI. This typically only ever needs to be done once in the entire lifetime of the project, so no need to have this be a user friendly process.
However, if it's a server you install your own instance of it's common to have a setup wizard, since each new install will need to go through this process, it's worth the effort to make something user friendly. You go to something like myapp.com/setup and then complete a few forms that sets up the first admin user and provides initial configuration and preferences. After this first admin user is setup this setup page would no longer be accessible, so that no other new admin users can be created that way.
Wordpress is a great example of the interactive setup. The end of this video has an example of what that looks like.
Usually when I'm in the midst of building my back-end I'll throw my own name into the user (model) via the users (routes) to test the puppy out.. i use Postman to inject my info into the endpoints points, then keep it there on the (mongo)db.. you could always use atlas to manual insert the user as well.
EDIT: my answer: use atlas to manually input a json file with the admin user of your clients (the company) choosing.
EDIT2: you've got me thinking... there could be an initialization state of the web-app where these things are declared; for example, say yo're creating an accounting management tool, in the first of a company initializing their new software you could request this information.
I am using Titanium.App.Properties to save user login (username and password) for user to login next time the app is started without typing the login credentials.
My question, is this the best way to do this and whether data saved in Titanium.App.Properties is encrypted and not accessible by any external app.
i think u can using Titanium Backup Root. cause This exhaustive app can save almost anything: apps, application data, messages, system settings, widgets, backgrounds, you name it.
I just noticed I cannot login in my Jenkins.
How can I reset my password and access to my account again? I do not see any link to recover passwords and they seem to be hashed in the installation directory.
In How to reset password of Jenkins you have a set of tricks to make this happen. I based my solution on it, but it diverges in a certain point.
This is what I did to solve the issue:
Let's assume Jenkins' directory is stored in $JENKINS (in my machine this is /var/lib/jenkins/) and your username is user.
Allow signups by disabling disableSignup. This means editing $JENKINS/config.xml and setting this option to false:
<disableSignup>false</disableSignup>
Restart Jenkins (service jenkins restart).
Enter in Jenkins and register a new user, for example testuser, with the password being the one you want to set to your user user.
Extract the hashed password from $JENKINS/users/testuser/config.xml. You will see something like:
<passwordHash>#jbcrypt:$2a$10$PY7p4dxFiGSgJpxiNVTQDuJKAQ8pr9snDgQXaafogjErvgB0oC3qy</passwordHash>
Set the user's password to this one in <passwordHash>. That is, edit $JENKINS/users/user/config.xml and replace the password there to set the one above.
Disallow signups back by enabling disableSignup. That is, in $JENKINS/config.xml set the disableSignup option back to true:
<disableSignup>true</disableSignup>
Restart Jenkins again.
Note you can also replace the password directly by generating a jBCrypt. For example, in http://www.mindrot.org/projects/jBCrypt/ you can find some Java code for it.
A different approach for Windows that solved this issue for me:
In
C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\config.xml, change useSecurity to false.
The restart Jenkins, you will now get full access without login. Go to People, select the old admin user and delete the user.
Then set
<disableSignup>false</disableSignup>
and
<useSecurity>true</useSecurity>
Restart Jenkins again, and you will now be able to register again.
Finally
<disableSignup>true</disableSignup>
I have written a simple application to authenticate user using PAM the common way: pam_start(), pam_authenticate() + my own conversation function + pam_end().
If application is run under the user who's credentials are being checked, authentication is succeeded. Otherwise, if application is run from user A to check credentials of user B, the authentication is failed. (
My question: why? As a service name passed to pam_start() I have tried also login as well as passwd. Nothing has changed. Which direction to go to debug the problem? Or possibly I should use another pam service to perform the task?
p.s. user 'A' in the second case is a user with no password and /bin/false shell.
How are you checking the "credentials"? Is it some file being read? Can user A read that file?
Service name passed to pam_start does not affect what the process can do. Note that programs that need to do similar things, like su or passwd are actually setuid programs.
Also, watch out not to create security holes in your application/module by allowing user A to impersonate user B.
User A might not have the permission to read the password file /etc/shadow. This is one reason why credential checking programs usually require root privileges.
So: Does it work for user A and user B if you execute the program with root privileges / as the root user?
I'm calling the Advapi32.dll LsaEnumerateAccountRights function having a policy handle from LsaOpenPolicy and an account SID from LookupAccountName.
However, try as I might, I'm always getting back 0xC0000034 which after translation by LsaNtStatusToWinError gives me "The file referenced cannot be found."
Which isn't a whole lot of good. My code handles this and goes on to grant the account SID the SeServiceLogonRight using LsaAddAccountRights, so I know that the policy handle and the account SID are fine as that would bomb out if something was wrong with one of those.
The end result is that the account does have the right it needs so overall the code works.
However, I'm using this within an MSI custom action, the Install checks to see if the account has the right and if it doesn't (or it fails as above) it grants the right and remembers it has done it in the install state. If a rollback happens and it added the right it then removes it. We never remove in an uninstall as other applications may have been installed using the same domain account that the services we run use.
So the problem is when an MSI performs a rollback - it will always remove the right as it always thinks it has added it. So checking the rights using LsaEnumerateAccountRights is used for this - but I just can't get it to work.
Any idea - please note that I'm using c# with DllImport attribute to expose the Win32 functions, and I'm not the worlds best Win32 programmer having been Unix before C#!
I have been struggling with this, too, but have just cracked it...
Retrospectively, I now see there was a clue in the msdn documentation:
"The accounts returned by this function hold the specified privilege directly through the user account, not as part of membership to a group."
See: link text
Get the policy handle from LsaOpenPolicy() and an account SID from LookupAccountName() exactly as you said.
If the username you entered was the name of a group ("Users", "Administrators", etc) then LsaEnumerateAccountRights() works fine and enumerates all the rights for the group.
If you call it on a username whose rights derive solely from the groups of which it is a member, then it returns 0xc0000034 (= Windows error 2 - The system cannot find the "file" specified), meaning (we now realise) "cannot find any individually assigned additional rights". It seems that the Windows Error 2 translation is a catch-all for "what you were looking for has not been found".
Now...
If you have ntrights.exe, run it... for example:
ntrights +r SeNetworkLogonRight -u MyUserName
Then, LsaEnumerateAccountRights() works fine, returns without error and enumerates a single right, "SeNetworkLogonRight".
I have recently run up against this same problem. In my testing with this issue it appears that the LookupAccountName call returns a security principal rather than the full SID. The actual failure seems to be that the section within the SID where the user rights would be is either not there or shortened to only the logon right.
Performing a LookupAccountName call on the current logged in user and then trying to LsaEnumerateAccountRights against that SID results in only the user logon right. Even though clearly, there are many other rights attached. Trying to retrieve any other users, other than the logged on user, successfully returns a SID. However, that SID will not have any user rights in it.
I have tested this on no domain workgroup systems and member systems of domains both as admin and regular users. The LookupAccountName call when successful, always results a SID that does not contain the full set of user rights.
I can only assume that if a complete SID could be obtained from the Security Database, then the LookupAccountName would properly iterate the rights.
I too have the exact same problem. Somebody suggested I get the SID via WMI with this query:
SELECT * FROM Win32_Account WHERE domain = 'ntdomain' AND name = 'username'
I tried it, using ConvertStringSidToSid() to get the magic blob LsaEnumerateAccountRights() expects and... same error. "The system cannot find the file specified."
I meet the same problem, it is because you dont assign spefic privledge to the user, so the user priveldge is empty, if you add one to it, it wont fail.
Call the same function with a group you can see everything working correctly.