topic Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.] in Data Management Questions

Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

TerryInniss — Fri, 07 Aug 2015 02:00:36 GMT

The sde database user is continually getting locked out of the database and the caption heading is the error message. Once the DBA unlocks it we are able to connect but as soon as we try to create the map service we get an error and on inspection we find the sde user is locked out. All the research has suggested that a MXD file with an old sde password is trying to connect to the database and hence locking it out. We have disconnected all arcmap instance yet the account still is being locked out. DO ANYONE has a suggestion for this issue.

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

George_Thompson — Fri, 07 Aug 2015 12:23:29 GMT

Hi Terry,

Can you provide a little more information related to the RDBMS being used? It looks like you are using Oracle but want to verify.

Do you happen to have other map services registered with the SDE user that may be using the incorrect password?

I am going to link to other groups with may help get more responses.

Geodatabase Managing Data Enterprise GIS

-George

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

AsrujitSengupta — Fri, 07 Aug 2015 13:22:51 GMT

After changing the password, resource the existing MXDs to point to the connection with the corrected password. Check if this helps!

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

TerryInniss — Fri, 07 Aug 2015 13:58:09 GMT

Thanks for replying. I am using ArcGIS for desktop 10.3.1 on Windows with an Oracle database (11g). I did create a map service. What is strange is that the user start getting locked out before I changed the password for the database user. Do you have any suggestions.

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

AsrujitSengupta — Fri, 07 Aug 2015 14:04:22 GMT

By any chance, does any of the Map Services\MXDs contain reference to any data that doesn't exist anymore?

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

TerryInniss — Sat, 08 Aug 2015 15:12:35 GMT

Thanks for the suggestions, they were very useful. When I stopped the arcgis service, the sde user stops getting locked out. Therefore, I deduced that the map service was using the old password and when user try to access that service it locked out the user. However, I have to restart the arcgis service to overwrite the old map service. I am hoping that when I restart the arcgis service, that the sde user will not be locked out. Is there any other way to do this that would not have me contacting the DBA because the sde user is locked out?

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

AsrujitSengupta — Sat, 08 Aug 2015 16:27:11 GMT

No, if the SDE user does get locked out, you'll have to contact the DBA to unlock it.

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

VinceAngelo — Wed, 12 Aug 2015 00:30:26 GMT

The SDE user should not EVER be used to publish services. Best practice doesn't even call for publishing as the data owner (you should always create at least one owner account to own spatial data [in a newly created tablespace]) -- an additional user with the least possible access (managed through roles) should be created exclusively for publishing. This will help prevent destruction of your geodatabase instance from a SQL injection attack.

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

KDeVogelaere — Mon, 09 Nov 2015 19:59:34 GMT

Is there a defect open to -

A. Allow users to programmatically disable the automatic connection attempts to RDBMS in ArcMap so when you open an MXD file with a changed .sde password it doesn't lock the account

B. Publish a POINTER to the .sde connection file instead of copying connection details into the MXD

Stricter security standards have been put in place for Oracle passwords at our company (expiry after 365-days and account lockout after 3-failed login attempts).

Best Regards,

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

KDeVogelaere — Tue, 12 Jan 2016 17:49:04 GMT

Does anyone know what the failed login attempt threshold is set for ArcMap? Does ArcMap stop attempting to connect to a database say after 100 failed login attempts?

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

VinceAngelo — Tue, 12 Jan 2016 18:02:30 GMT

I don't believe there is any failed attempt threshold. Each time you request an attempt to connect, that connection will be attempted (once). ArcGIS Server manages connection pools differently, but I'm not aware on any limit there either (probably only a frequency thing -- retry interval, not retry count).

- V

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

KDeVogelaere — Tue, 12 Jan 2016 18:14:26 GMT

Vince,

That is interesting. It seems ArcMap is using (at least) 3 failed-login attempts and locking the ID every time an MXD (containing a bad username and/or password) is opened with datasource data stored in Oracle. Our Oracle standards allow 3-failed login attempts before locking the Oracle ID. This is a company-wide standard to prevent brute force attacks. I would think ArcMap stops trying to connect after 4,5,6,etc. failed connection attempts, but maybe I'm wrong and ArcGIS Server and ArcMap only have a frequency setting as you suggest.

-K

Re: Failed to connect to database Underlying DBMS error[ORD-28000: the account is locked No extended error.]

VinceAngelo — Tue, 12 Jan 2016 18:27:51 GMT

Look at how layers are modelled. Each layer is associated with a connection (zero or one). Connection pooling (successful connects) will prevent additional connections to the same set of parameters, but unsuccessful connections will not pool (and therefore effectively retry).

Unfortunately, three and done on service-oriented accounts is an effective denial of service attack.

- V