Application Login not working unless Windows Authentication works in SQL Server - sql-server

I have a database set up that is to gather planned vacation time that I need to put on sharepoint asap. It's completely done, except for that the application login is failing for anyone that tries to use it that does not have their corprate login (windows authentication) listed in the security logins folder.
The connection string is fine, as it works properly on my computer and another programmer's computer, but not on my boss's computer. I can also login to sql server using the application login that is listed in the connection string.
I'm using SQL Server Managment Studio 2008, the server is 2005.
Edit#1: Further research led to finding this page: http://sql-articles.com/articles/troubleshooting/troubleshooting-login-failed-error-18456/
And my error is state 11. It's listing a windows authentication in the error log even though I specified otherwise.
Edit#2: My Connection String is this:
Driver={SQL Server};Server=ServerName\ThingIdontUnderstand;Database=ReportingDevDB;Trusted_Connection=FALSE;uid=Derp;pwd=qwerty;
Edit#3: Solved! See comments on this post for answers since I can't answer my own questions yet.

You check for the version when you connect to the instance through SSMS it will show it beside the server name under Object Explorer. Or just use the query SELECT ##VERSION
I would suggest simply creating a corporate windows group and adding those individuals to it, and then simply add this group as a login to your instance of SQL Server.

Related

Laravel 8 connect to SQL Server [duplicate]

I am trying to host a SQL server database, but whenever I try to connect to it I get this error:
The login is from an untrusted domain and cannot be used with Windows
authentication
I am connecting through Matlab using the following command:
conn = database('Clinical_Data','DoyleLab07\Acc','','com.microsoft.sqlserver.jdbc.SQLServerDriver','jdbc:sqlserver://DOYLELAB07\SQLEXPRESS:54287;database=Clinical_Data;integratedSecurity=true;').
Connecting to the database using matlab worked fine as long as I was using matlab on the computer which I was using to host the server. However, when I use another computer and the same Matlab command I get the error I showed above.
When I look under control panel\system. I notice that no domain is listed on my host PC or the PC I am using to connect to the host, but both computers are in the same workgroup. Would I be able to fix my problem by creating a domain and adding the foreign PC and the host to that domain? If so, how can this be accomplished?
Any suggestions will be very much appreciated.
Thank you for reading my post.
Getting rid of Integrated Security=true worked for me.
In order to use Windows Authentication one of two things needs to be true:
You are executing from the same machine as the database server.
You have an Active Directory environment and the user the application is executing under (usually the logged in user) has rights to connect to that database.
If neither of those are true you have to do one of two things:
Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
Change SQL server to use both Windows and SQL Server accounts.
By FAR the easiest way is to change SQL Server to use both Windows and SQL server accounts. Then you just need to create a sql server user on the DB server and change your connection string to do that.
Best case option 1 will take a full day of installation and configuration. Option 2 ought to take about 5 minutes.
If your SQL Server is on one domain controller and you are trying to connect to it from another domain controller then you will get this error when
IntegratedSecurity = true;
This will happen even if you include a valid SQL Server username and password in your connection string as they will automatically be over-written with your windows login and password. Integrated security means simply - use your windows credentials for login verification to SQL Server. So, if you are logged in to a different domain controller then it will fail. In the case where you are on two different domain controllers then you have no choice but to use
IntegratedSecurity = false;
Now, when Integrated security is false SQL Server will use the SQL Server login and password provided in your connection string. For this to work, the SQL Server instance has to have its authentication mode configured to mixed mode, being, SQL Server and Windows Authentication mode.
To verify or change this setting in SQL Server you can open the SQL Server Management Studio and right-click on your server name and then select Properties. On the pop-up that appears select Security and you will see where to alter this setting if you need to.
I've had this same issue when using DNS aliases and hosts files to connect to a machine using a different domain name.
Say you have a SQL server called sql1 on mydomain.com - which is an Active Directory domain - and you also have a DNS zone for mydomain.net, and - for consistency - you set up a DNS alias (CNAME) record for database.mydomain.net --> sql1.mydomain.com
You'll be able to connect to sql1.mydomain.com using Windows integrated security, but won't be able to connect to database.mydomain.net even though it's the same server because the domain name doesn't match your AD domain.
This error message can also occur if the account you are using to access the SQL server is locked out by the domain.
I was facing the issue while connecting to SQL Always On Listener. Disabling the loop back check resolved the issue.
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck”
Set this value to 1
https://blog.sqlauthority.com/2017/04/18/sql-server-login-failed-login-untrusted-domain-cannot-used-windows-authentication/
Why not use a SQL Server account and pass both the user name and password?
Here is the reason why.
In short, it looks like you have an authentication issue.
The problem with workgroups is there is no common Access Control List like Active Directory (AD). If you are using ODBC or JDBC, the wrong credentials are passed.
Even if you create a local windows account (LWA) on the machine (SE) that has SQL Express installed (SE\LWA), the credentials that will be passed from your client machine (CM) will be CM\LWA.
As mentioned here, you might need to disable the loopback
Loopback check can be removed by adding a registry entry as follows:
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck” Set this value to 1
If you using windows authentication make sure that password of the user hasn't expired. An expired password can explain this error. This was the problem in my case.
Same Error with Connection String in Visual Studio dev environment
Our development database server was recently given a self-signed certificate so it automatically became untrusted. This resulted in the login error cited above. I added TrustServerCertificate=True to my connection string and it works now.
"Server=TheServerAddress; Database=TheDataBase; User Id=TheUsername; Password=ThePassword; TrustServerCertificate=True"
NOTE: This certificate configuration is not recommended for production environments.
In my case the Aliases within SQL Native Client 11.0 Configuration were pointing to invalid server/IP. Once updated it worked correctly.
To check:
1. Start "SQL Server Configuration Manager"
2. Navigate to "SQL Native Client 11.0 Configuration" and then "Aliases"
3. Ensure "Alias Name" and "Server" match correctly for TCP/IP
Following worked for me to get access from another machine to SQL Server using Windows Authentication. This approach may be useful only in development/test environment. E.g. you need to update password manually once you change it on your working machine.
On machine with SQL Server go to Control Panel and add new Windows User with same username and password as is on your working machine. Then create SQL Server login for this user:
CREATE LOGIN [SQLSERVERHOST\myuser] FROM WINDOWS;
Now you can use this login for Windows Authentication.
If you receive error 'The login is from an untrusted domain', this may mean that you changed password on your working machine and now need to update password on SQL Server machine.
Just adding my suggestion for a resolution, I had a copy of a VM server for developing and testing, I created the database on that with 'sa' having ownership on the db.
I then restored the database onto the live VM server but I was getting the same error mentioned even though the data was still returning correctly. I looked up the 'sa' user mappings and could see it wasn't mapped to the database when I tried to apply the mapping I got a another error "Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405". so I ran this instead
ALTER AUTHORIZATION ON DATABASE::dbname TO sa
I rechecked the user mappings and it was now assigned to my db and it fixed a lot of access issues for me.
Joining a WORKGROUP then rejoining the domain fixed this issue for me.
I got this error while using Virtual Box VM's. The issue started to happen when I moved the VM files to a new drive location or computer.
Hope this helps the VM folks.
We now use a privileged account management solution that changes our passwords regularly. I ended up receiving this error after my password was changed. Closing and re-opening SSMS with the new password resolved my issue.
I started to get this error when i tried to login to SSMS using 'windows Authentication'. This started to happen after i renamed the Windows SQL server. I tried everything to resolve this error and in my particular case changing the machine names in the 'hosts' file to reflect the name SQL server name change resolved the issue. C:\Windows\System32\Drivers\etc\hosts
I had this problem because we where using a DNS name from an old server, ponting to a new server. Using the newserver\inst1 address, worked. both newserver\inst1 and oldserver\inst1 pointed to the same IP.
Yet another thing to check:We had our nightly QA restore job stop working all of a sudden after another developer remoted into the QA server and tried to start the restore job during the middle of the day, which subsequently failed with the "untrusted domain" message. Somehow the server pointed to be the job's maintenance plan was (changed?) using the ip address, instead of the local machine's name. Upon replacing with the machine name the issue was resolved.
TLDR: Changing the DNS server to the loop back address worked for me.
I am working in VirtualBox and had setup two Windows Server 2016 instances. Server A is configure as a Domain Controller and Server B as an SQL Server. After adding Server B to the domain I cold not connect to with Management Studio from Server A. I was getting the "The login is from an untrusted domain and cannot be used with Windows authentication".
My initial configuration had the server getting its IP from the VirtualBox DHCP server.
I changed this to use static IP and entered the 127.0.0.1 address in the Primary DNS and this worked for me.
Hope this helps someone passing by.
I enabled Trust Server Certificate in the Connection Properties and it worked for me
You might find out that you have more than one connection string, and you forgot to change the other one to Integrated Security to false. It happened to me. This answer might help someone.
I was focusing on the web config and the access rights, after a long hustle i remembered that I have another connection string in one of my classes for the emails, I had to change the connection string on the class to use the web config one.
i removed Integrated Security=true and Trusted_Connection=True both of them , worked for me..
In .net Core also you may get this error if Trusted_Connection=True;
Is set. Sample setting in appsettings.json
ConnectionStrings": {
"DefaultConnection": "Server=serverName; Database=DbName; uid=userId; pwd=password; MultipleActiveResultSets=true"
},
Sometime SSMS hang and close all of sudden ,then you get below error when you reconnect to SSMS
i) The Login is From an Untrusted Domain and Cannot be Used with Windows Authentication
OR
ii) The target principal name is incorrect .Cannot generate SSPI context.
In both cases RESTART YOUR MACHINE.
I also had a similar error but then I realised I just had changed the password for my system which caused this error.
To resolve it , I simply logged out of the current session and logged in again and this time
Please Use This Connection URL It's Work Fine
"Data Source=Your IP Address;Initial Catalog = DatabaseName;User ID =sa;Password =your PassWord;TrustServerCertificate=True"
Example : "Data Source=192.168.150.122;Initial Catalog=StudentDb;User ID=sa; PassWord=123;TrustServerCertificate=True"
If you have two servers on the same domain (eg. APP and DB), you can also use Windows Authentication between the app and MSSQL by setting up local users on both machines that match (same username and password). If you don't have the passwords matched up, it can throw this error.
Following was working for me. hope this helps you
<add name="getconn" connectionString="Data Source=servername;Initial Catalog=DBName;Persist Security Info=True;User ID=sa;Password=***" />

Force drop an MSSQL login?

I can't drop a newly created login, as the server keeps throwing the "Could not drop login '(..)' as the user is currently logged in. (Microsoft SQL Server, Error: 15434)".
The login was created a few minutes earlier and used once from a .NET web app, the web app has been shut down (the whole IIS server is stopped), the SQL server has been restarted several times and the session table is empty.
What could be causing the server to still think the user is logged in, and how can I fix it?
You must be aware, that each window of your SQL Server Management Studio keeps its own connection open.
You are in conflict with your own SSMS query window...
Just as a little story:
I once had a query prepared for a test system. When everything was running fine I disconnected the SSMS server pane from the test system and re-connected it to the identical productive system. As the database's name was the same I just executed the file and was very surprised, that I got errors like "object already exists...". It took me a while to find, that the open query was still running against the test system. There is no obvious hint to reflect this...
(Thanks to Shnugo's comment for the solution)
Apparently the SQL Server Management Studio is what kept the user logged in, even though I had disconnected and re-connected with my Windows username. A simple SSMS restart solved the problem.

SQL Server 2012 SSDT "The project could not be deployed to .... A connection cannot be made ...."

I'm a newbie to SQL Server 2012. Here is my condition.
I have a running SQL Server 2012 Business Intelligence SP1. The problem is I cannot deploy a project to my SSAS from another computer.
The error is:
The project could not be deployed to the 'DATABASE-SERVER\MSSQLSERVER' server because of the following connectivity problems : A connection cannot be made to redirector. Ensure that 'SQL Browser' service is running. To verify or update the name of the target server, right-click on the project in Solution Explorer, select Project Properties, click on the Deployment tab, and then enter the name of the server.
The following is the things that I've tried:
Check the target name on Project > Properties > Deployment > Target server.
Check the server service --> all SQL Server services are running.
The project can be deployed from server.
The connection to server is clear
I can connect to the Database Engine and Analysis Service from another computer from SQL Server Management Studio.
Please help me to fix this problem, I've been search for many days for this problem.
Thank you, sorry for my bad english.
Best regards, Stella.
I had the same problem, for me the solution was to explicitly specify login information on the Impersonation Information tab on the Data Source.
I know this is an old thread, but I had the same issue and I reckon more will run into this buzz saw.
My problem was that the remote installation of SSAS did not have an Inbound firewall rule for SSAS application; msmdsrv.exe.
Resolution:
Log on to the server running SSAS as Administrator
Launch Windows Firewall and advanced Security
Add Inbound Rule, give it a meaningful name like SQL Server - SSAS
Action: Allow the connection
On Program and Services Tab: For 'This Program' use Browse and identify msmdsrv.exe
For SQL Server 2014, it is by default here:
%ProgramFiles%\Microsoft SQL Server\MSAS12.SQLSVR14\OLAP\bin\msmdsrv.exe
(Very similar for 2012 and 2016, the numbers are different)
Click OK; You should see a green dot with check mark
Try your project again; It should connect, did for me.
NOTE: If this also work for you, consider going back to the Inbound Rule and consider adding connection restrictions for security reasons.
I solved mine by right clicking my data source (under Data Sources in Solution Explorer) → Edit in the General tab → In Connection Manager, do two things:
Change Server name from localhost to your computer name
Use SQL Server Authentication as Authentication, as opposed to Windows Authentication, and proceed to enter your user name and password (the "sa" password you use for SSMS).

Trouble Connecting to sql server Login failed. "The login is from an untrusted domain and cannot be used with Windows authentication"

I am trying to host a SQL server database, but whenever I try to connect to it I get this error:
The login is from an untrusted domain and cannot be used with Windows
authentication
I am connecting through Matlab using the following command:
conn = database('Clinical_Data','DoyleLab07\Acc','','com.microsoft.sqlserver.jdbc.SQLServerDriver','jdbc:sqlserver://DOYLELAB07\SQLEXPRESS:54287;database=Clinical_Data;integratedSecurity=true;').
Connecting to the database using matlab worked fine as long as I was using matlab on the computer which I was using to host the server. However, when I use another computer and the same Matlab command I get the error I showed above.
When I look under control panel\system. I notice that no domain is listed on my host PC or the PC I am using to connect to the host, but both computers are in the same workgroup. Would I be able to fix my problem by creating a domain and adding the foreign PC and the host to that domain? If so, how can this be accomplished?
Any suggestions will be very much appreciated.
Thank you for reading my post.
Getting rid of Integrated Security=true worked for me.
In order to use Windows Authentication one of two things needs to be true:
You are executing from the same machine as the database server.
You have an Active Directory environment and the user the application is executing under (usually the logged in user) has rights to connect to that database.
If neither of those are true you have to do one of two things:
Establish a Windows Domain Controller, connect all of the relevant machines to that controller, then fix SQL server to use domain accounts; OR,
Change SQL server to use both Windows and SQL Server accounts.
By FAR the easiest way is to change SQL Server to use both Windows and SQL server accounts. Then you just need to create a sql server user on the DB server and change your connection string to do that.
Best case option 1 will take a full day of installation and configuration. Option 2 ought to take about 5 minutes.
If your SQL Server is on one domain controller and you are trying to connect to it from another domain controller then you will get this error when
IntegratedSecurity = true;
This will happen even if you include a valid SQL Server username and password in your connection string as they will automatically be over-written with your windows login and password. Integrated security means simply - use your windows credentials for login verification to SQL Server. So, if you are logged in to a different domain controller then it will fail. In the case where you are on two different domain controllers then you have no choice but to use
IntegratedSecurity = false;
Now, when Integrated security is false SQL Server will use the SQL Server login and password provided in your connection string. For this to work, the SQL Server instance has to have its authentication mode configured to mixed mode, being, SQL Server and Windows Authentication mode.
To verify or change this setting in SQL Server you can open the SQL Server Management Studio and right-click on your server name and then select Properties. On the pop-up that appears select Security and you will see where to alter this setting if you need to.
I've had this same issue when using DNS aliases and hosts files to connect to a machine using a different domain name.
Say you have a SQL server called sql1 on mydomain.com - which is an Active Directory domain - and you also have a DNS zone for mydomain.net, and - for consistency - you set up a DNS alias (CNAME) record for database.mydomain.net --> sql1.mydomain.com
You'll be able to connect to sql1.mydomain.com using Windows integrated security, but won't be able to connect to database.mydomain.net even though it's the same server because the domain name doesn't match your AD domain.
This error message can also occur if the account you are using to access the SQL server is locked out by the domain.
I was facing the issue while connecting to SQL Always On Listener. Disabling the loop back check resolved the issue.
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck”
Set this value to 1
https://blog.sqlauthority.com/2017/04/18/sql-server-login-failed-login-untrusted-domain-cannot-used-windows-authentication/
Why not use a SQL Server account and pass both the user name and password?
Here is the reason why.
In short, it looks like you have an authentication issue.
The problem with workgroups is there is no common Access Control List like Active Directory (AD). If you are using ODBC or JDBC, the wrong credentials are passed.
Even if you create a local windows account (LWA) on the machine (SE) that has SQL Express installed (SE\LWA), the credentials that will be passed from your client machine (CM) will be CM\LWA.
As mentioned here, you might need to disable the loopback
Loopback check can be removed by adding a registry entry as follows:
Edit the registry using regedit. (Start –> Run > Regedit )
Navigate to: HKLM\System\CurrentControlSet\Control\LSA
Add a DWORD value called “DisableLoopbackCheck” Set this value to 1
If you using windows authentication make sure that password of the user hasn't expired. An expired password can explain this error. This was the problem in my case.
Same Error with Connection String in Visual Studio dev environment
Our development database server was recently given a self-signed certificate so it automatically became untrusted. This resulted in the login error cited above. I added TrustServerCertificate=True to my connection string and it works now.
"Server=TheServerAddress; Database=TheDataBase; User Id=TheUsername; Password=ThePassword; TrustServerCertificate=True"
NOTE: This certificate configuration is not recommended for production environments.
In my case the Aliases within SQL Native Client 11.0 Configuration were pointing to invalid server/IP. Once updated it worked correctly.
To check:
1. Start "SQL Server Configuration Manager"
2. Navigate to "SQL Native Client 11.0 Configuration" and then "Aliases"
3. Ensure "Alias Name" and "Server" match correctly for TCP/IP
Following worked for me to get access from another machine to SQL Server using Windows Authentication. This approach may be useful only in development/test environment. E.g. you need to update password manually once you change it on your working machine.
On machine with SQL Server go to Control Panel and add new Windows User with same username and password as is on your working machine. Then create SQL Server login for this user:
CREATE LOGIN [SQLSERVERHOST\myuser] FROM WINDOWS;
Now you can use this login for Windows Authentication.
If you receive error 'The login is from an untrusted domain', this may mean that you changed password on your working machine and now need to update password on SQL Server machine.
Just adding my suggestion for a resolution, I had a copy of a VM server for developing and testing, I created the database on that with 'sa' having ownership on the db.
I then restored the database onto the live VM server but I was getting the same error mentioned even though the data was still returning correctly. I looked up the 'sa' user mappings and could see it wasn't mapped to the database when I tried to apply the mapping I got a another error "Fix: Cannot use the special principal ‘sa’. Microsoft SQL Server, Error: 15405". so I ran this instead
ALTER AUTHORIZATION ON DATABASE::dbname TO sa
I rechecked the user mappings and it was now assigned to my db and it fixed a lot of access issues for me.
Joining a WORKGROUP then rejoining the domain fixed this issue for me.
I got this error while using Virtual Box VM's. The issue started to happen when I moved the VM files to a new drive location or computer.
Hope this helps the VM folks.
We now use a privileged account management solution that changes our passwords regularly. I ended up receiving this error after my password was changed. Closing and re-opening SSMS with the new password resolved my issue.
I started to get this error when i tried to login to SSMS using 'windows Authentication'. This started to happen after i renamed the Windows SQL server. I tried everything to resolve this error and in my particular case changing the machine names in the 'hosts' file to reflect the name SQL server name change resolved the issue. C:\Windows\System32\Drivers\etc\hosts
I had this problem because we where using a DNS name from an old server, ponting to a new server. Using the newserver\inst1 address, worked. both newserver\inst1 and oldserver\inst1 pointed to the same IP.
Yet another thing to check:We had our nightly QA restore job stop working all of a sudden after another developer remoted into the QA server and tried to start the restore job during the middle of the day, which subsequently failed with the "untrusted domain" message. Somehow the server pointed to be the job's maintenance plan was (changed?) using the ip address, instead of the local machine's name. Upon replacing with the machine name the issue was resolved.
TLDR: Changing the DNS server to the loop back address worked for me.
I am working in VirtualBox and had setup two Windows Server 2016 instances. Server A is configure as a Domain Controller and Server B as an SQL Server. After adding Server B to the domain I cold not connect to with Management Studio from Server A. I was getting the "The login is from an untrusted domain and cannot be used with Windows authentication".
My initial configuration had the server getting its IP from the VirtualBox DHCP server.
I changed this to use static IP and entered the 127.0.0.1 address in the Primary DNS and this worked for me.
Hope this helps someone passing by.
I enabled Trust Server Certificate in the Connection Properties and it worked for me
You might find out that you have more than one connection string, and you forgot to change the other one to Integrated Security to false. It happened to me. This answer might help someone.
I was focusing on the web config and the access rights, after a long hustle i remembered that I have another connection string in one of my classes for the emails, I had to change the connection string on the class to use the web config one.
i removed Integrated Security=true and Trusted_Connection=True both of them , worked for me..
In .net Core also you may get this error if Trusted_Connection=True;
Is set. Sample setting in appsettings.json
ConnectionStrings": {
"DefaultConnection": "Server=serverName; Database=DbName; uid=userId; pwd=password; MultipleActiveResultSets=true"
},
Sometime SSMS hang and close all of sudden ,then you get below error when you reconnect to SSMS
i) The Login is From an Untrusted Domain and Cannot be Used with Windows Authentication
OR
ii) The target principal name is incorrect .Cannot generate SSPI context.
In both cases RESTART YOUR MACHINE.
I also had a similar error but then I realised I just had changed the password for my system which caused this error.
To resolve it , I simply logged out of the current session and logged in again and this time
Please Use This Connection URL It's Work Fine
"Data Source=Your IP Address;Initial Catalog = DatabaseName;User ID =sa;Password =your PassWord;TrustServerCertificate=True"
Example : "Data Source=192.168.150.122;Initial Catalog=StudentDb;User ID=sa; PassWord=123;TrustServerCertificate=True"
If you have two servers on the same domain (eg. APP and DB), you can also use Windows Authentication between the app and MSSQL by setting up local users on both machines that match (same username and password). If you don't have the passwords matched up, it can throw this error.
Following was working for me. hope this helps you
<add name="getconn" connectionString="Data Source=servername;Initial Catalog=DBName;Persist Security Info=True;User ID=sa;Password=***" />

Error connecting to SQL Server using SQL Server Management Studio

I've been trying to connect to SQL Server using SQL Server Management Studio to no avail.
This is what the error says:
Cannot connect to .\HAMED.
ADDITIONAL INFORMATION:
Login failed for user 'HAMED'. (Microsoft SQL Server, Error: 18456)
I have an instance of SQL Server by the name of Hamed which is run in Network Sevice mode. I'm using Windows 7.
I'm guessing you didn't grant yourself SQL admin during the install, but are you sure the DB instance is "HAMED"? That sounds like the machine name. Try connecting to .\sqlexpress
Do you remember the SA password? If so, you can add yourself by logging in with that account. Otherwise, you'll have to jump through some hoops and loops to get yourself added.
If you forgot to add yourself to the SQL admin group, read this article:
http://blogs.ameriteach.com/chris-randall/2009/12/11/sql-server-2008-forgot-to-add-an-administrator-account.html
It looks like you're trying to use "SQL Server Authentication" in the login dialog in SSMS, but the user that you're trying to use is a Windows user/administrator? If so, the fix should be as simple as choosing "Windows Authentication" in the drop-down.
UPDATE: looks like I jumped the gun - this sql server forum thread lists lots of possible issues, including permissions issues, orphan users, etc.
sa... the answer was sa.
I had set the administrative password but didn't know the username to go with it. Very nube, I know, you can hit me with it later.
When I installed SQL it asked me to set administrative password - right now SSMS can login.
Under users I see 1\cory (1 is my machine name - I'm trying a numbering scheme). But if I type that in it fails with the error. SQL says "no, that's an NT login, I can't use those".
Under the users list SQL does in fact show the user as Windows authentication but as I said - for some reason I can't connect using Windows authentication. The connection times out.
I'll just add a direct user name here.
All this is to do the MSVA courses for SQL certification. First exam: get sql SSMS to work.

Resources