Integrated Security without joining the domain (1 Viewer)

[SuperShin]

I have an Outlook 365 .accdb that i link tables to an old 2008 R2 Windows 2008 SQL machine using Trusted authentication via our Active Directory

Connection string was DRIVER=SQL Server;SERVER=10.10.10.50;Trusted_Connection=Yes;APP=Microsoft Office;Network=DBMSSOCN

We are in the process of migrating that server to a 2016 Windows/2016 SQL box.

In the past my development machine was NOT joined to the domain, and I just insured that my password and user name was the same as my active directory account and everything worked fine for decades+

Now the connection string is of course its all on the same network

Connection string was DRIVER=SQL Server;SERVER=10.10.10.65;Trusted_Connection=Yes;APP=Microsoft Office;Network=DBMSSOCN


Now that I'm moving to 2016 SQL from 2008 i get the following error:

Connection failed
SQL State: 28000
Microsoft ODBC SQL SERVER DRIVER LOGIN FAILED
The Login is from an untrusted domain and cannot be used with integrted authetnication.

So this is due to my dev machine not being on the domain via active directory HOWEVER my user/account pass are the same as my active directory account. I dont want to put my dev machine on the domain what am i missing? It had always fallen over to KERBEROS auth in the past when the domain wasn't available.

Other users on the domain can use it fine and IF I login first authenticate the domain by running in an admin shell:

runas /user:domain\myusername/netonly "C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE"

then open the DBase im good to go -- but i hate that, I just want it to work as it did by defaulting back to Kerberos.

Can anyone point me in the right direction?

 

[tvanstiphout]

> HOWEVER my user/account pass are the same as my active directory account
That does not matter much; the SID is different.

MSFT increases security with each version of Windows Server. Your previous loophole (if one could call it that) is likely no longer supported.
So join the domain, and use your Windows Firewall to block traffic you don't want (if you want to go to that extent).

 

[SuperShin]

I dont think thats accurate because I can still run if I simply authenticate the domain in a runas without joining the domain. Joining the domain is clearly not required.


runas /user:domain\myusername/netonly "C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE"

 

[tvanstiphout]

I didn't say impersonation does not work anymore. Surely it does. My point was that the "Kerberos loophole" may have been fixed.
You said "but i hate that, I just want it to work as it did by defaulting back to Kerberos." so I figured that's not what you want to do.

 

[Minty]

Kerberos authentication linking (from memory) has been deprecated in more modern versions of Windows/Exchange Server.
If it is still supported I think it requires a different authentication method that doesn't support impersonation for obvious reasons.

 

[SQL_Hell]

Bit of a shot in the dark, but does the new 2016 server have a SPN created for kerberos authentication?

 

[SuperShin]

Well Thanks for everyone's input Ill just make a batch file for myself and my dev machine that does a runas and all the other users won't need to deal with the issue, its just annoying to me when things work and then an update breaks something....have i talked to you yet about not being able to link an access front end to a backend via ip address on a FLAT VLAN local ip address only....if i had two access issues to really complain about this year it would be that and this.