Sarge

Really depends how your sudoers is setup, out of the box RHEL, CentOS and Mint don't require the above change. Shucks. Thanks guys.

Hi, Yes, it's possible. It's far easier if you use LDAP or IPA. You'll need to add the following lines to sudoers. Where <username> is the username of the priv account to handle the resets. Next... Create a linux host which can be used to reset the Priv Account credentials when they expire. (Assuming they do expire, ours do, so we reset our priv account creds 10 days prior to it's actual expiration date) Create the credentials for the priv account in a Password List enabled for password resets, link the creds to the host created above, and enable resets. Make sure validation and reset status have worked. Assuming they have, keep going with step 4. Create a priv account in Passwordstate > Administration > Privileged Account Credentials, and link it to existing credentials. (Created step 2) Create the host for which you want to reset root password. In a Password List enabled for resets, create the current root users credentials; enable them for validation and resets. On the reset options tab ensure you select the Priv Account you created previously. On the heartbeat options tab ensure you tick "Use the Privileged Account Credential selected on the 'Reset Options' tab to perform the authentication for this validation (only used for Linux root accounts if required): " As soon as you click save it will go off and reset the root password, assuming you've done everything correctly it'll go through without an issue. Details can also be found in the user manual. Make sure you've test against your dev environment prior to implementing in production.

ClickStudios could use a noSQL database just for bad passwords. That's largely what gives Azure Tables its performance.

Get-ADDomain will tell you the functional level of the domain. It would work as a solution in Matts case. Obviously it wouldn't work if the DCs are Server 2003 though.

Looks like regardless of the resolution, its an issue if the window is resized. Even at 1920 * 1200, if I resize the window no scroll bars appear in the content pane. (Safari, Chrome, Firefox)

How would your idea work if the user has the same UPN in multiple AD environments? How will the Passwordstate know that Joe@subdomain.domain.com.au wants to reset his production password, if Joe@subdomain.domain.com.au (which is his UPN / email address as you mentioned) is the same in development, production, uat, sit, prac etc? When having multiple AD environments there is no need to ensure each users data within that environment isn't the same; however there is a requirement to ensure the NetBIOS name / FQDN of the domain is unique on the network. Therefore it's easy to imagine multiple reasons where multiple AD domains would have the same user data with the only unique factor being the FQDN of the domain. Just for clarity, this isn't about authenticating users to one domain. This is about authenticating users to multiple domains - particularly a development or production instances - where company standards dictate that usernames should be the same. We can easily add a suffix to our AD environments, and then update a few thousand users to use that new suffix - there for forming a UPN of "user@production.domain.com.au" or "user@development.domain.com.au" but that doesn't solve anything. Users shouldn't have to remember the suffix (Or NetBIOS name). We could add the email subdomain (lets assume its 'staff.domain.com.au') to our AD environments, then update the users to use that new suffix, but then we have the same UPN between multiple AD environments where it's "user@staff.domain.com.au" to authenticate to production or development - how would Passwordstate know which one to reset? The best way to solve it would be to use data you know will be unique - which is the FQDN (or NetBIOS name) of the domain itself, rather than assuming users UPNs will be unique.

That wouldn't work for us. That assumes the users know what the domain is - if they know what the domain is then they know the NetBIOS name and can just use domain\user. However our users don't know what the domain is (nor do they need to) - they just know they want to reset their "Production" or "Development" password. Being able to have a drop down, where they choose "Production Environment" or "Development" or "UAT", and enter their username (which is the same format between environments) is far easier than expecting users to remember or enter the UPN or prepend with NetBIOS. Let the users do the easy lifting and the program do the harder lifting by prepending (or appending) the required information. Since Passwordstate is aware of the NetBIOS name, it shouldn't be hard for it to interpret that a drop down box selection means it should prepend the NetBIOS name of the chosen domain to the username field. You could possibly go further, and add a "Local" option to the drop down, whereby Passwordstate would interpret this to mean the user wants to reset their credentials for Passwordstate application itself (If using forms). Currently if a user doesn't remember their password they need to see a Passwordstate administrator to resend the welcome email.

We sure do. It's for wider business use - sys admins, developers, 'average joes' doing app testing etc, networks team etc. They know they want to reset for development or production environment, but not know (nor remember) what the NetBios domain portion is.

Can it be an option? Ours will never be exposed to the internet, and our users don't know what to prepend the username with - they just know they are logging into production or development environment. If the domains can have a customizable friendly name then I can't see what information it will expose about the internal domain?

I just noticed in the the self service portal, with two domain accounts added, there doesn't seem to be a way to specify for which domain you want to enroll or reset the password to. Can that be added via a drop down menu on the enroll screen and login screens for self service? (Ideally with the ability to label the domain with a 'friendly name' such as "Production AD")

Nope.

I can replicate the issue at 1440 * 900

Nope, but it did have modify rights earlier in this thread. The rights have been dropped since then. I believe it was when I re-deployed v8 because of the issues I was having. *shurg*

Fixed, granted Network Service modify required permissions to c:\inetpub\passwordstate

I'm now getting the following error when I try to access the system settings.