I am in a unique situation where I need to test my server connectivity to Oracle databases however I do not have access to any account or password.
Reason why the connectivity needs to be tested is because many times there are multiple layers of firewalls between my servers and the database, and also particularly recently while trying to access RAC/Exadata databases we realized that doing a telnet on the "scan" IP range (which were the only range visible to me) was not enough and that there are underlying physical/virtual IPs that are actually used to connect which were blocked. If I can test connectivity I can at least confirm the database is accessible.
I thought about connecting using sqlplus test#DB, where "test" account doesn't actually exist. If I get a reply saying that incorrect username/password logon denied, then at least I know the database connectivity is working because at least it reached the database to perform authentication. But I have audit concerns (whether DBAs will think someone is trying to hack the system) and also whether there's an actual way or command to do this test.
like #OldProgrammer pointed out, this is pretty much an optimal case for tnsping from the command line
tnsping MY_SERVICE_NAME
Here's a good post showing the basic options. Oh, and I'm pretty sure the DBA's can still see the traffic if they want to.
I am a .Net / SQL Server programmer. I am trying to make an Access database created by someone else to work. It looks like is uses a procedure similar to Save password for ODBC connection to SQL Server from MS Access 2007 but I am using Access 2003 so I suspect something else needs to be done. I don't really know what I am doing with Access but I am stuck with it.
I do have an ODBC connection and it looks like the linked tables use it. The database has an AutoExec which populates some local tables from the linked tables that the reports use. It also calls a qryConnect with a dsn-less connection like the linked article and this seems to work. I have got it to stop asking for a user and password on start up. I can also open most reports without problems, 2 do not work. A form loads on Startup with buttons that basically show reports. This is where it gets odd.
The reports fail from the ODBC driver with the windows credentials. Then a logon box shows up with the correct user (a user with read only privileges) but the trusted connection box is checked. I do not have the trusted box checked in the DSN. Not do I have Trusted_Connection=Yes in the DSN-less connection in qryConnect.
This is the code in the form
stDocName = "rptNegativeLotQtys"
DoCmd.OpenReport stDocName, acPreview
I don't know how I buggered it up so much and before I try again copying everything to a new mdb and trying again I am hoping to get some guidance.
On a side note I can open everything fine on my machine. I am an administrator as far as Windows is concerned but not SQL Server.
EDIT:
I created a new DSN just for these reports. Then I deleted all linked tables and re-linked then using the new DSN. I looked at the linked tables in MsysObjects and the new DSN is listed there. Yet Access still prompts for the password. It appears that it is not caching the password.
Actually, you do NOT need to add nor store the UID/Pass in the connection strings used. However, what you MUST ensure is that all connection strings are the SAME. If they are different, then the cached UID/password will not work.
Also, make sure you do NOT connect nor open a table AFTER having connected using Windows Auth – the reason being then when you add the table links (especially via code), then the cached setup of using windows auth will occur, and thus prompts will occur when the links suggest to do otherwise. In other words linking and attempted to use SQL logons will NOT work if you already opened any table link via windows auth (so exit the database and do NOT open any table that could/can use windows auth).
So I would delete the links, and re-create them – but again, ensure that you never connected as a windows auth user to SQL server.
So the "cache" that access has is a GREAT friend/feature to eliminate the need to include UID/pass in the connection string - but the SAME feature will bite you VERY bad if you at any time connecte to the database in question via windows auth.
How to “cache” the user logon and ID is explained here:
Power Tip: Improve the security of database connections
http://blogs.office.com/b/microsoft-access/archive/2011/04/08/power-tip-improve-the-security-of-database-connections.aspx
So you “can” include the UID/LOGON in the linked tables, but above shows that a ONE time logon can also be used. So be VERY careful when setting up table links – due to the above “cache” of the user and HOW they logged into the database – code that ATTEMPTS to create table links based SQL logons will actually wind up using windows auth if you already connected as such (so exit the database if you going to re-link using SQL logons).
Keep in mind, Access does NOT use the DSN AFTER you linked the table. The information from the DSN is a ONE TIME copy to the connection string. You can verify this by going into my documents and deleting the DSN you used. Assuming the linked table was working correctly, you find that they CONTINUE to work EVEN if you delete the DSN. In effect this means that linked tables are DSN less except for when you create the linked table. This allows you to easy copy the application to different computers without having to copy the DSN.
As to ensure that all the linked tables use the same connection string, it is a simple matter to delete them all, and re-link.
You can also hit ctrl-g to bring up the debug window, and look at the connection string this way:
? currentdb.TableDefs("linked table name").Connect
the result in the debug window for a windows auth connection string will look like this:
ODBC;Description=test DSN;DRIVER=SQL Server;
SERVER=albertkallal-pc\SQLEXPRESS;
Trusted_Connection=Yes;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Note how in above we see "trusted connection" (that means windows auth).
If I linked the table using SQL logon (and REMEMBER to check save password), then you see this:
ODBC;Description=TEST3;DRIVER=SQL Server;
SERVER=ALBERTKALLAL-PC\SQLEXPRESS;
UID=MySQLogon;PWD=MyPassword;
APP=Microsoft Office 2010;DATABASE=AxisMIS
Just remember during the table link process to "check" the save password.
eg this:
My problem with database starts with situation where I cant really modify anything in database. My project specialist has limited time to help me. Here is the thing:
My user in Oracle database has older schema than actual production one. My section is working on stable and older version. After every release we are keep getting this issue, that something is set (maybe on Jenkins, maybe not) automatically to update our database to version, which we dont want. We tried to resolve it by changing password to user, but it produce new issue. Automat is trying to log in and when it gets wrong pass error, it is trying again. Oracle 11g has this limit 10 failed login attempts, after which it is locking the whole user account, which we use to connect do db by our application server.
We can not investigate this by turning on auditing failed logins, because it takes place on database space and our db-guy has not allowed us to do it, because if we exceed the space limit (which is about 11GB) the whole database will be dead (our project is not as important to do it). Another thing is that person who probably set the scripts which are our problem doesnt work anymore here.
Our workaround was to manually unlock account to get the connection by application server, and then wait a few secs to get locked again (but the connection of app server was stable). It is stupid, you must admit and the problem is when the connection drops by any reason - app server will not get it automatically, we have to do it manually which is not a solution. I have reconsidered it all again, my db-guy has no time to help me, I have no tools and access rights to investigate where this script or whatever other problem causing thing is beeing executed, so I started to thinking: what if we set limit of failed login attempts to unlimited? Will this decrease the performance of database? Will this generate any special new problems? Maybe the solution would be change the PASSWORD_LOCK_TIME to small value? I am asking you to some arguments that I could provide to my db-guy to convince him to use this new workarounds so I can start working again with code and not this database problems.
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
I'm trying to install SQL Server 2008 development server on my local machine as administrator.
During the installation I receive this error, any idea how to solve it?thanks
[Error Message]
The credentials you provided for the SQL Server Agent service are invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
[Details]
Microsoft.SqlServer.Configuration.Agent.InputValidationException: The credentials you provided for the SQL Server Agent service are
invalid. To continue, provide a valid account and password for the SQL
Server Agent service.
Use the credential that you use to login to PC. Username can be searched by Clicking in sequence
Advanced -> Find -> Choose your Username -> (e.g. JOHNSMITH_HP/John)
Password must be same as your windows login password
There you go !!
I solved using as credential built-in accounts as the NetworkService
this article point me out in the right direction
http://www.sqlcoffee.com/SQLServer2008_0013.htm
Under the "Account Name" Drop Box choose Browse.
Type the user name that you used to log in to windows on the
"Enter the object name to select" and then click "Check Names".
Click "Ok".
Under "Password" just type the password that you used for windows login.
In my case it was more of a Microsoft bug, than an actual issue. I installed under the Administrator login and used strong password btw but I was still getting this error constantly.
I tried to install with Windows credential without entering the password, but that did not go through either. Was getting the same error.
Then I cleared all password textboxes manually and copies the correct password in each text box. Hit enter, and it went through.
The error was most likely misleading.
There seem to be several problems that can cause this symptom. To tell them apart, one needs to look in the setup log files in %PROGRAMFILES%\Microsoft SQL Server\[versionnumber]\Setup Bootstrap\Log, probably Detail.txt.
According to this article, when running the installer as a local administrator and trying to use a domain account for the service, it may claim that the credentials are invalid because the local administrator does not have sufficient permissions in the domain to look up the service account's SID. This was the main problem I was encountering, and it might be what was affecting the original poster a year and a half ago.
I've had this error as a result of trying to use a cloned VM that had the same SID as the domain. The two options to fix it were: sysprep (or rebuild) the database server OR dcpromo the DC down and back up to change the domain SID.
I found I had to be logged in as a domain user.
It gave me this error when I was logged in as local machine Administrator and trying to add domain service account.
Logged in as domain user (but admin on machine) and it accepted the credentials.
In my case password was expired. Change the password and try the step again.
Well I have been battling to understand why, when at the Account section of the installation of a second node, the system will not accept the password I used to log in. I have been scratching my head - reading every post under the sun all to no avail.
I did notice that some service accounts were given as service.instname.instno#FDNdomain.com and others were given as DOMAIN\service.instname.instno (the latter being the Win2000 version)
I also noticed comments about strength of password so I thought - I can do that so I changed the password to a much higher strength and RDC in to the server - with new password and thought - best to update the services on the existing node first. I stopped the service, clicked on password and pasted in from the clipboard - (can't go wrong eh?) ha ha says Windows.. Got ya.. it wouldn't accept the password - that I just logged in with. I clicked on browse to select the service account and VOILA! the account name changed to the DOMAIN\user version and readily accepted the password. I then repeated the exercise on the other service. I then found that the node installation would continue (after backing up and forward through the process) to pick up the new name format and accepted the passwords without complaint.
I think the moral of this experience is to use the wizards and select through the "browse" button rather than manually entering the service name.
I hope my experience saves someone else the pain I went through.
Still Confused
I had a domain account with a strong password, but it didn´t work, then I used Network Service account. I tried to change it on SQL Server Configuration Manager after installation and it worked.
Taking SQL Server cluster role offline-Online on node 1 worked for me.
I had a VM that was server 2012 and I had to change the nic to VMXNET 3. It wasn't connecting to the domain fast enough for the services to start I guess.
the button 'Use same account' below thee main window will fill in all the textboxes automatically. this worked fpr me.
You might encounter one of these three problems:
Password Policy Violation, find valuable information here: https://msdn.microsoft.com/en-us/library/ms161959.aspx
Password not starting with a "character"
Domain Service User's account might be locked.
A blog post with the summary for all three possible problems might be found here:
https://cms4j.wordpress.com/2016/11/29/0x851c0001-the-credentials-you-provided-for-the-sqlserveragent-service-is-invalid/
ActiveDirectory Server 2003
I am using the ActiveDirectoryMembershipProvider and ADroleProvider. They work great. Until my active directory server restarts in the middle of the day to get updates. (I'm not in charge of the server and can't change this). When this happens, for the five minutes the server is rebooting, my users can't use my website because I've tied my menu to the Role Provider. So, here are my questions:
Is it possible to tell my RoleProvider to use the "next" available ADS? If so, how so that while the initial one reboots, I don't frustrate my users with ADS connection messages?
Should I be using some kind of connection pool that automatically reconnects to the available server? If so, how?
Let's imagine that all my active directory servers go down. Is there a way to keep my web application running? Obviously there are bigger problems if all servers are down, but what I'm after is a possible "disconnected" active directory authentication that will still move forward if the server somehow goes kaput. Is this wise AND possible?
You probably have the server connection string set to "server01.domain.local". If you change it to just "domain.local" you're no longer depending on "server01" being online. Instead you will use the Round Robin feature of Active Directory DNS to get a list of all domain controllers and use one that's online. (I don't think your admins reboot all of the domain controllers at the same time...)
Also try running nslookup domain.local a couple of times in succession in a command prompt to see the order changing.