Prevent credentials from being stored in MXD when using connection file?

[danan]

I have an SDE connection file. I add a data source to an MXD using the connection file. If things worked according to what seems to be standard connection file behavior in other products, I should be able to delete the connection file; and the next time I open the MXD referencing it, the data source referencing that connection file should be broken. However, when I delete the connection file, the data source is not broken. This indicates that credentials are being copied into the MXD.

Q1) Can I prevent credentials from being copied into the MXD, yet still use connection files? e.g. I don't want any prompts for u/n and p/w

Q2) How secure is the encrypted password in an MXD? Although this may be a moot point if merely passing around an MXD gets one access to all SDE data sources in it--sensitive info might easily be accessed this way without proper authorization.

Q3) Why was the connection file behavior implemented this way? Evidently, most software products using connection files do not copy credentials into product files--they merely store a reference to the connection file.

Q4) Is this behavior likely to change in the future? I haven't checked on 10, but at 9.3.1, credentials still seem to get copied into MXDs.

Thanks.

[RandyKreuziger]

Q1) Can I prevent credentials from being copied into the MXD, yet still use connection files? e.g. I don't want any prompts for u/n and p/w

Q2) How secure is the encrypted password in an MXD? Although this may be a moot point if merely passing around an MXD gets one access to all SDE data sources in it--sensitive info might easily be accessed this way without proper authorization.

Q3) Why was the connection file behavior implemented this way? Evidently, most software products using connection files do not copy credentials into product files--they merely store a reference to the connection file.

Q4) Is this behavior likely to change in the future? I haven't checked on 10, but at 9.3.1, credentials still seem to get copied into MXDs.

Use operating system authentication if you can.  Then MXDs and layer files files can be passed around without worry.  There won't be any credentials stored and no prompts.  Only the SDE layer that user has access to will be visible when the MXD is opened.  I don't know of OSA works only when Microsoft SQL Server is the database.

We are moving to a server new server where all users will be OSA.  But right now on our current server we have a mix of both OSA and SQL logins.  Some MXDs have been passed around and now have 2 or 3 credentials embedded.  When opened it shows in SDE that 3  different users are connected.  When I need to kick users off of SDE I don't know which of the 3, if any, is the real user connected.

[danan]

Use operating system authentication if you can.  Then MXDs and layer files files can be passed around without worry.  There won't be any credentials stored and no prompts.  Only the SDE layer that user has access to will be visible when the MXD is opened.  I don't know of OSA works only when Microsoft SQL Server is the database.

We are moving to a server new server where all users will be OSA.  But right now on our current server we have a mix of both OSA and SQL logins.  Some MXDs have been passed around and now have 2 or 3 credentials embedded.  When opened it shows in SDE that 3  different users are connected.  When I need to kick users off of SDE I don't know which of the 3, if any, is the real user connected.

Thanks Randy. We're an Oracle shop at the moment. My question is related to a deployment of ArcGIS Server where an app account uses a connection file. Can anyone here with SDE on Oracle experience comment?

[RobertHu]

Q1) Can I prevent credentials from being copied into the MXD, yet still use connection files? e.g. I don't want any prompts for u/n and p/w

Q2) How secure is the encrypted password in an MXD? Although this may be a moot point if merely passing around an MXD gets one access to all SDE data sources in it--sensitive info might easily be accessed this way without proper authorization.

Q3) Why was the connection file behavior implemented this way? Evidently, most software products using connection files do not copy credentials into product files--they merely store a reference to the connection file.

A1) While creating your SDE database connection, uncheck the "Save username and password" box. The mxd create using that connection should not have your username/password embedded. It is a little bit annoying when another person opens it at first time.

A2) I don't know exactly how secure a password is in a mxd. But in a ESRI training class, I did ask same question. The answer from the instructor was something like as for as he knows, nobody ever complained or reported to ESRI that the password not secure enough in mxd.

A3) I think the purpose is to make map sharing very easy. Believe me, lots, lots of people like it this way, even we as DBA hate it so much. If you have concerns, as Randy indicated, using the OSA is probably the best solution. If OSA doesn't work for you, try A1.

Robert