Sarge

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.

Haven't been able to test it out, mainly because I can't figure out how to actually access it. Sent myself an enrolment email, followed the URL (which resolves to the passwordstate server); it takes me to https://<url>/enroll which just gives me a page not found error.

Seems to be. I had it sync an AD group just before knocking off for the day. Are you able to shot me through expected pricing for that module (if pricing has been decided yet)? If the self service password resets work as expected it will be a massive help for us. The rest of v8 seems quite good so far. I'll be testing the Linux password resets tomorrow for root users as well.