Windows is responsible for user name and password
When The user list is already filtered against current users - if you see someone in the list, it means that AD user is not currently bound to a SuperOffice user.
The gray ones
These uses do not have a valid First Name / Last Name in AD, so we can not populate our Person from them. Talk to your admin! - Or create a new user, using password authentication (that means you fill in the Person dialog yourself); then click the [...] to change the authentication to the AD user you need (who is not going to be grayed out in this mode).
Maintaining Links
The link to an AD identity is based on the SID, not the name so the AD user name changes have no effect - everything still works
SuperOffice user name can be renamed, and we'll try to rename the users document folder in SO_arc for you. Do this if you need to, not for fun
In most cases, SuperOffice name = AD name is the way to go.
The little [...] button can be used to change authentication method. You can link up an existing user to AD, and vice versa. This does not change anything about the associate, only the authentication method
Columns in the user list can be set to show authentication type
Changing authentication method is like changing your socks - it may get you into your Club or not, but it doesn't really change who you are inside of SuperOffice. Remember that a SuperOffice identity is an associate, and those are not affected by authentication changes. Only how you convince the system you are that associate changes. So you can play with this safely, as much as you want.
Integrated logon - Windows
Remember that we now first try to log in using the Windows Identity, if this fails then the login dialog is shown (it takes a few seconds more to show up)
If you are set up with AD authentication, then you will never see the login dialog.
To log on as someone else, right-click the program shortcut and choose the Run as... option; you then need to know the password of that someone
This used to be a property of the ODBC connection. That is no longer the case and it is important to turn off that option otherwise the Windows user needs to be a database user, and we're no longer in the db-user business.
Integrated login is a catch-all: since it is integrated, it happens without asking (otherwise it wouldn't be integrated, right?). That means you can't override it once it has started - you have to override it before you start.
"Integrated login" in ODBC is a completely different matter. In effect you are telling the ODBC driver, "ignore whatever username and password is present, and log on as my Windows Identity". That is absolutely not the same as integrated logon to SuperOffice! Turn off integrated logon in ODBC, unless you really want to have a policy where every AD user is mapped to a database user, and want to maintain things that way.