Remove password from MXD

[AllanBenvin]

We have a large user base that often shares mxds with one another. It is far too easy for a user to save their password in an mxd and then give it to another user. If the first user then changes their password, their Oracle account will get locked by the other user opening his mxd.

There appears to be no easy way to resolve this other than tracking down every single mxd on the network and local PC and deleting it.

ArcMap and ArcCatalog treat connections to the same instance/server as the same. In other words if in Catalog I have a connection as the SDE user to an instance called SDE_DEV, and I then open an anonymous connection file to SDE_DEV, I get connected automatically as the SDE user.

The same thing happens when you try to change the data source from a saved connection to an anonymous connection, because the server, instance are the same, nothing happens and your password is still saved.

I have tried the arcpy "findAndReplaceWorkspacePaths" but this will not remove saved passwords to the same instance. Another problem with this is that it does a string search and replace based on the name of the connection file. If 10 users create a connection file to the same db, what are the chances of the conn file names and paths being the same and useful for search and replace? If instead the search and replace worked on the basis of server/instance and was able to change username/pwd and remove any saved passwords then this would be useful for SDE.

Using local/user specific connection files and saving passwords is workable with small shops but in a large environment with hundreds of users, the potential to save mxds with passwords and share them creates huge problems.

I think I am done venting now.

[DavidWatkins]

As I understand this, findAndReplaceWorkspacePaths should be able to do what you are asking for.  This is from the help found at: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00s30000004p000000

"In this scenario, a user wants to remove the password information saved within a map document. The data sources in the map document came from an SDE connection file where the password information was saved with the connection information. Next, the user created a new SDE connection file to the same database but this time did not save the password information. In the script below, the validate parameter must be set to False for the password information to be successfully removed. After the script is run, a user will need to log in to open the resulting map document."

import arcpy
mxd = arcpy.mapping.MapDocument(r"C:\Project\Project_default.mxd")
mxd.findAndReplaceWorkspacePaths(r"C:\Project\Connection with password info saved.sde", 
                                 r"C:\Project\Connection with no password info saved.sde", False)
mxd.saveACopy(r"C:\Project\Project_NP.mxd")
del mxd

This should remove the saved password. Is this not working as you are expecting?

[KevinDunlop]

I have the same problem as you.  We have several users who use the same SDE database. Each have their own username and password to the database.  Users create connections with the username and password saved in the connection since they don't want to enter ther login info everytime the open ArcMap.  When they share mxds, their username and passwords are saved in the mxd so now I have users who are working with other users' account names because they are using a shared mxd.

What I would love to see is that all username and passwords are removed from saved mxd (or at least given a setting to remove them).  The connection name should be saved in mxd so if I have all my users with a SDE connection that has the same name such as MasterPlanSDE, ArcMap should automatically set all layers to use their personal connection and not the mxd's author's connection.  If the user doesn't have access to a certain layer, then they should get a red ! for that layer.

It seems like the current SDE security model is based on a 1 user/1 project model.  In an enterprise environment, you will have several users who will end up working on the same set of mxds before they are complete si 1 user/1 project doesn't work.

[TracyJones]

I understand that their may be a arcpy script for this but a number of our users would not have the ability or knowledge to use this Having a button that could do this directly in ArcMap would be very useful - I'm also in a large shop and this is a big problem. Thanks.

[AllanBenvin]

Yes,  "findAndReplaceWorkspacePaths" should be able to do what I am asking for but it does not.

It can break the connection but it does not repoint it to an anonymous connection. After following the example supplied by David, the username/password connection is removed from the mxd but when the mxd is opened it does not prompt for the uesrname/password as a normal anonymous connection does. Instead the layers just have the red exclamation mark and each layer must be re-pathed manually.

I will submit a ticket with support for this but I still believe a tool built in to Catalog that could "anonymize" mxds would be a great help for any organization that has moved beyond shapefiles and file geodatabases.

[StephanImfeld]

This is also a security issue!
Saving passwords in MXD and layer files prevents effective password management, i.e. regularily changing passwords in the database.
Opening one single MXD with an outdated stored password (e.g. 10 layers) locks the database account. Every time you open the MXD!
Exchanging passwords for data holding accounts (e.g. after a change in personel) is practically impossible, as it would quickly result in a lock down of all accounts as soon as older MXDs are being opened.
We should either be able to remove all passwords (maybe for specified accounts?) from all available MXDs or have the option to ignore stored passwords when opening MXD or layer files.

[AllanBenvin]

Update, I got my script to work. "findAndReplaceWorkspacePaths" does work but only if your new connection file is stored on a UNC path. It won't work if your new anonymous connection file is on your local machine.
(Yes I know this makes absolutely no sense.)

The other thing I had to do was make the connection parameters different in the anonymous connection file. If the instance and server are the same, nothing will change. I had to append the full domain name to the server to make it different ('server.stuff.here'). This is a pain because if I run the tool again I will have to change the server name back to just 'server'.

[MichaelVolz]

Allan:

Though not a solution for your current mxds, maybe a workflow change could resolve this issue in the future.  Are the users who share the mxds actually making edits to the Oracle SDE data?  Or are they just viewing the data and changing the labels and symbology for a specific project?

You might consider using lyr files for data that is shared in multiple mxds where you have a generic account with only viewing privileges with the password saved so the user does not need to know the credentials for the SDE connection. Then for the data editors, they would have specific SDE connections that only they would use with credentials only known by them.  You would have a far greater number of mxds with just viewing privileges and a much lower number of mxds with specific editing privileges.  The mxds with the editing privileges would not allowed to be shared so the editing privileges cannot be used by anyone but the individual with the specific editing privileges against the Oracle SDE database.