locked out of SDE account

[JimBerry]

ArcGIS10 - Windows XP: SDE account password had to be changed. Older mxds have older password stored for SDE layers. Three consecutive "failed password" attempts (just by opening the mxds) locks me out of the SDE. Can mxds be "fixed" to not try and make the "doomed to fail" SDE connections for the "older" password layers? Or, could my SDE login credential be "freed" from the "three consecutive failed logins" conundrum?

[VinceAngelo]

You *really* shouldn't be using the "SDE" login for mapping, and leaving the old SDE
login password in MXDs is bound to cause this exact problem (or worse).  You haven't
said what database you're using, but for Oracle, a search on "oracle lock out incorrect
password" returned the (quite risky, in the long term) procedure to disable expiration.

Since you need to rework all your MXDs anyway, this would be a good time to make
sure that:
1) The SDE user password is very closely held,
2) The SDE user doesn't own any spatial tables,
3) No user data is located in the SDE tablespace,
4) The data ownership account isn't used for browse access,
5) All accesses to tables are performed through GRANTs to roles.

Ideally, each user would connect to the database as themselves (no shared login),
and common MXDs would have the connection properties set so that the password
isn't retained.

Searching for links to MXD editing procedures (using "change password in MXD"),
I found a document with a very important caveat:

Please note that for all connections using Database authentication that saving the username and password and sharing map documents (MXD files) which have this authentication information used within them is a potential security risk.

- V

[MichaelVolz]

Vince:

You wrote:

Ideally, each user would connect to the database as themselves (no shared login),
and common MXDs would have the connection properties set so that the password
isn't retained.

What happens if you need to update the SDE connection information in these common mxds (numbering in the thousands) and a manual process is impractical based on budgetary constraints (this scenario exists if you move the SDE database to a new server for upgrade)? I have created VBA and python scripts that loop through the mxds on my organization's network. Mxds where the password is not retained are problematic to the automatic processing of these files as the scripts hang at this point looking for an enduser to add the connection information.

Don't you think this is a liability of not retaining the SDE connection information in the mxds?

[VinceAngelo]

I haven't had to deal with this personally, but I'd imagine you could keep two copies of each MXD,
one with the generic browse user password, and the second with password retention disabled.
Users grab from the second pool, but that pool is created via scripting from the first pool (which
is closely held).  The publishing proceess would need to be amended, but dealing with a thousand
of anything generally requires a "policies and procedures" doc.

You might also publish only with a shared read-only user, so that users would be encouraged to
use their own logins (or time-limit the shared login to force use of their own logins in frustration).

There's probably dozens of solutions, though not all of them are practical at all sites.

If I had them to spend, my UC "Esri dollars" would go to more robust transition tools.

- V