Jump to content
Sarge

Discovered Issues/Bugs...

Recommended Posts

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")

 

Share this post


Link to post
Share on other sites

Hi Sarge,

 

As long as the Username is not the same, you shouldn't need to prefix any domain information. If you do however have duplicate Usernames, then you need to specify something like domain1\msand or domain2\msand. instead of just msand.

 

Can you try this and let us know if you have any issues?

We also intentionally didn't want a domain dropdown list on this screen, as it can expose information about your internal domain - we envisage that customers will probably install the reset portal in their DMZ, and make it accessible via the Internet - so we didn't want any "leakage" of domain information. I hope that makes sense.

Regards

Click Studios

Share this post


Link to post
Share on other sites
46 minutes ago, support said:

We also intentionally didn't want a domain dropdown list on this screen, as it can expose information about your internal domain - we envisage that customers will probably install the reset portal in their DMZ, and make it accessible via the Internet - so we didn't want any "leakage" of domain information. I hope that makes sense.

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?

Share this post


Link to post
Share on other sites

Hi Sarge,

 

We could look at this as a feature request, but as per our email we sent out, we will be working on feature requests after the beta has finished - so it might take some time before we can get to it.

 

So I'm guessing that you have duplicate Usernames between your production and development domains? Is the development domain for your IT guys, or the wider business? We would have thought the IT team would know the domains, but we could be wrong. We also tried to model this like OWA for Exchange, and Microsoft require you to prefix the NetBIOS domain portion for their software.

Regards

Click Studios

Share this post


Link to post
Share on other sites
13 minutes ago, support said:

So I'm guessing that you have duplicate Usernames between your production and development domains?

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.

Share this post


Link to post
Share on other sites

Thanks for clarifying Sarge - we also just had a second request for the same thing via an email request.

 

Guess we've got some work to do :)

Regards
Click Studios

Share this post


Link to post
Share on other sites

A solution could probably be to use Userprinciplenames (user@domain) instead of the Pre-Win2000-Logon-Name (domain\user). As I understand, this is wished in this feature request.

 

As far as I now, it's best practice to configure the Userprinciplename to the same as the Email-Address and tell the user, to use their Email-Address to logon. The most applications are using the Userprinciplename to logon instead of the Pre-Win2000-Logon-Name, because Pre-Win-2000 is legacy.

 

Best regards,

 

Fabian

Share this post


Link to post
Share on other sites
13 minutes ago, Fabian Näf said:

A solution could probably be to use Userprinciplenames (user@domain) instead of the Pre-Win2000-Logon-Name (domain\user).

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.

Share this post


Link to post
Share on other sites
Quote

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.

 

No, the user don't need to know his domain. They just need to know their Email-Address, which every user knows. Prerequisite is, that the Userprinciplename is configured equal to the Email-Address in Active Directory, but this is best practice.

http://blogs.perficient.com/microsoft/2015/07/office-365-why-your-upn-should-match-your-primary-smtp-address/

Share this post


Link to post
Share on other sites
25 minutes ago, Fabian Näf said:

No, the user don't need to know his domain. They just need to know their Email-Address, which every user knows. Prerequisite is, that the Userprinciplename is configured equal to the Email-Address in Active Directory, but this is best practice.

 

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×