SQL server Windows authorisatie via ODBC login probleem

[eatualive]

Hallo mensen,

Ik ben bezig om een SQL server op te zetten voor mijn applicatie. Ik ben niet heel bekend met SQL server maar heel mijn SQL server is zo goed als ingericht en mijn database zit erin.

Ook heb ik SQL authenticatie werkend en ik kan met mijn client inloggen op mijn SQL server en naar de database schrijven. Ik draai SQL server 2012. Tot zover geen problemen.

Echter na wat research word windows authenticate aangeraden boven SQL authenticatie. De users heb ik toegevoegd met de juiste permissies(Ga ik vanuit aangezien de SQL authenticatie op de zelfde manier werkt). Mijn SQL server draait trouwens op een windows 7 professional PC zonder domein. Totzover geen gekke dingen.

Nu wil ik ODBC configureren op mijn client pc. Ik start de wizard en ik wil een naam en descriptive in.
Vervolgens zoek ik naar de server op het network en deze wordt gevonden.

Als ik vervolgens op volgende klik dan wordt er gevraagd " How should SQL Server verify then authenticity of the login ID?"

Ik kies dus nu with intergrated windows authentication. Nu moet ik iets invullen bij SPN maar als ik in de documentatie kijk dan praten ze de hele tijd over het domein. Ik heb geen domein maar gewoon een pc dus ik vul in computernaa\user.

Als ik vervolgens door ga en de default database wil kiezen dan krijg ik de melding connection failed.
SQLState: '28000'
SQL server error: 18456
[driver ...] Login failed for user computernaam\guest.

Kortom hij logt altijd in als guest. Wat doe ik fout? Of moet ik guest configureren in mijn sql server? Ik zou zeggen dat ik toch een Eigen user moet kunnen configureren?.

Ik hoop dat iemand mij kan helpen want het is waarschijnlijk iets heel kleins wat ik over het hoofd zie.

[sanfranjake]

Je pc zit niet in een domein, dus volgens mij moet je dan SQL authenticatie gebruiken. Want vziw kan je niet een user als pc2\user toevoegen op je sql-server op pc1. SPN = Service Principle Name, iets wat je in Active Directory definieert.

[eatualive]

Ja daar ben ik ook bang voor maar ik kan het niet duidelijk uit de documentatie halen.
Als het zo is dan is dat geen probleem al had windows authenticate mijn voorkeur.

Als het niet kan dan houd het op en ga ik verder met sql authenticatie.

[Verwijderd]

Het zou als het goed is gewoon moeten werken als je in plaats van je lokale computernaam die van je server opgeeft. Dus in plaats van CLIENTNAME\user -> SERVERNAME\user (het windows account die je dus ook op je server gebruikt) in je ODBC verbinding.

Wellicht kom je hier verder mee: http://msdn.microsoft.com...96.aspx#paght000008_step1

[ Voor 19% gewijzigd door Verwijderd op 03-05-2013 13:33 ]

[Viper®]

Wat je met windows authentication doet is voor het aanloggen gebruik maken van je windows authenticated account. Als je binnen een active domain zit is dit je domain account en deze is als beide servers in hetzelfde domain aangemeld zijn voor beide beschikbaar.

Omdat je geen domain hebt gaat dit niet werken. Je account pc1\Testaccount is bij pc2 namelijk niet bekend.

Wat je zou kunnen doen is op beide machines hetzelfde account aanmaken met dezelfde naam en hetzelfde wachtwoord. Probleem wat dit met zich meebrengt is dat je account's synchronisatie hebt, wat naar mijn idee maar problemen met zich meebrengt dan dat het oplost. Als je niet over een domain beschikt zou ik persoonlijk voor SQL authenticatie gaan.

[CMD-Snake]

Heb je in SQL Server ook aangezet dat deze remote verbinding accepteert? Staat normaal uit, kan je in de attack surface wizard allemaal configureren.

Welke poort draai je op? Normaal is 1433. Die staat standaard dicht in de Windows firewall. Moet je even openzetten.

Deze bovenstaande dingen worden ook nog wel eens vergeten en dan krijg je ook vreemde meldingen.

Je kan voor authenticatie je SQL Server ook op mixed mode zetten. Zowel Windows authentication als SQL authentication (En als je dit wijzigt moet je de DB opnieuw starten.) Dan ben je niet afhankelijk van lokale accounts op de PC zelf.

[ Voor 15% gewijzigd door CMD-Snake op 03-05-2013 13:47 ]

[eatualive]

@CDM-Snake Ja daar was ik de eerste keer al tegen aangelopen. Maar dat heb ik zelf werkend gekregen. Ik heb inderdaad poort 1433 open gezet op de TCP all instellingen.

@didierstouten, zo heb ik het dus geprobeerd te testen maar dit lukte niet. Ik denk dat 'viper' de rede van mijn problem omschrijft tenzij jij heel zeker weet dat het zo kan werken.

@viper ik denk dat het problem wat ik heb inderdaad is zoals jij het omschrijft. Al zou ik zeggen uit logica dat het account alleen aanwezig moet zijn op de server. Maar SPN zal waarschijnlijk alleen functioneren onder active directory en zal ik het account dus ook op de client moeten aanmaken zoals jij omschrijft. Dan denk ik dat de beste oplossing SQL authenticatie is voor mijn toepassing. Ik had het mooi gevonden dat ik het alleen aan de server kant moet configuerren.