Kennwort-Richtlinie erzwingen abschalten

[Cre@or]

Hi, ich habe folgendes Problem.
Zunächst einmal, es geht um die Installation eines Programmes.
Dieses läuft ab MS SQL 8.0.
Mit der MSDE 2000 funktioniert die Installation fehlerfrei.
Nun habe ich die Installation unter MS SQL 2005 getestet und zack, (faust ins Gesicht) lief das ganze nicht mehr so rund.
Ich lasse eine Bat ausführen:

net start MSSQL$Instanz
copy Datei1.mdf "Ermittelter Pfad zum MS SQL SVR"
copy Datei2.LDF "Ermittelter Pfad zum MS SQL SVR"
osql -U Benutzername -P Passwort -i Datei3.txt

Tja, net start funktioniert, copy Datei1.mdf und copy Datei2.LDF funktioniert auch...
osql... funktioniert nicht mehr, hier bekomme ich folgende Meldung in der Eingabeaufforderung angezeigt:

Das Kennwort ist nicht komplex genug und erfüllt daher nicht die Anforderungen der Windows-Richtlinie.

Ich habe bereits 45 Zeichen lange Kennwörter vergeben, die große und kleine Buchstaben und Ziffern enthalten.
Bei einem zweiten Test bei dem ich die Checked-Eigenschaft der Checkbox mit der Caption "Kennwortrichtlinie erzwingen" manuell auf False gesetzt habe (man könnte auch sagen, ich habe das Häkchen entfernt), bekam ich wieder diese Meldung.
Also meine Frage, kann ich diese Zurückweißung des von mir gewählten PW in der Bat unterbinden?
Ich hab schon die halbe Registry nach einem Eintrag durchsucht, aber bisher nix gefunden, und google konnte mich auch nicht weiterbringen.

Bin für jeden / jede Hinweiß / Lösung dankbar.

mfg Cre@or

[Cre@or]

Kann mir denn keiner Helfen?
Ich weiss einfach nicht mehr weiter...
Ich hab jetzt schon ne ganze Weile gesucht und nix gefunden, auch probiert habe ich so einiges aber alles umsonst...
Ich hoffe mir kann irgend jemand helfen [Hände über den Kopf werf]...

mfg Cre@or

[O. Helper]

Hast Du Dich wirklich an die Richtlinie gehalten; ich vermisse bei Deiner Ausführung das Sonderzeichen.

Das Kennwort enthält weder den ganzen noch Teile des Kontonamens des Benutzers. Als Teil eines Kontonamens werden drei oder mehr aufeinander folgende alphanumerische Zeichen definiert, die an beiden Enden durch Leerraum (wie z. B. Leerzeichen, Tabulatoren und Wagenrücklauf) oder eines der folgenden Zeichen begrenzt werden: Komma (,), Punkt (.), Bindestrich (-), Unterstrich (_) oder Nummernzeichen (#).

- Das Kennwort ist wenigstens acht Zeichen lang.
- Das Kennwort enthält Zeichen aus drei der folgenden vier Kategorien:
o Lateinische Großbuchstaben (A - Z)
o Lateinische Kleinbuchstaben (a - z)
o 10 Grundziffern (0 - 9)
o Nicht alphanumerische Zeichen, wie z. B.: Ausrufezeichen (!), Dollarzeichen ($), Nummernzeichen (#) oder Prozentzeichen (%)

Kennwörter können bis zu 128 Zeichen lang sein. Sie sollten möglichst lange und komplexe Kennwörter verwenden.

Ansonsten kann ich nur empfehlen, die Windows-Authentifizierung zu nutzen, damit hat man solche Probleme nicht.

[Cre@or]

Naja, es ist nur vorgeschrieben das 3 der 4 Vorschriften eingehalten werden müssen:

Beschreibung
Legt fest, ob Kennwörter den Komplexitätsvoraussetzungen entsprechen müssen.

Wurde diese Richtlinie aktiviert, müssen Kennwörter die folgenden Mindestvoraussetzungen erfüllen:

Sie dürfen weder einen Teil noch den vollständigen Kontonamen des jeweiligen Benutzers enthalten.
Sie müssen mindestens sechs Zeichen lang sein.
Sie müssen Zeichen aus drei der vier folgenden Kategorien enthalten:
Großbuchstaben von A bis Z
Kleinbuchstaben von A bis Z
Ziffern der Basis 10 (0 bis 9)
Nicht-Alphanumerische Zeichen (z. B. !, $, #, %)
Die Einhaltung der Komplexitätsvoraussetzungen wird bei der Erstellung oder Änderung von Kennwörtern erzwungen.

Informationen zum Erstellen von benutzerdefinierten Kennwortfiltern finden Sie im Microsoft Platform Software Development Kit und bei Microsoft Technet.

Voreinstellung: Deaktiviert.

Naja, es ist ja folgendes, während der Installation des MSSQL 2005 akzeptiert er ja das angegebene Passwort für den Benutzer sa.
Und wenn ich dann die Installation über diesen laufen lassen will, hat er auf einmal Probleme damit.
Nur so als Hinweiß.

[O. Helper]

Kannst Du Dich den mit "sa" + dem Passwort über das Management Studio an die Datenbank anmelden?

[Cre@or]

Ich habe es ausprobiert und ja, ich kann mich anmelden.
Ich kann diese auch als Standartdatenbank festlegen.
Ich bin jetzt nicht so ein großer Kenner der Microsoft SQL Server-Familie, deswegen bedanke ich mich schon mal hiermit für die Unterstützung deinerseits.

mfg Cre@or

[Cre@or]

Vielleicht hilft noch folgende Information weiter, ich bekomme beim ausführen von osql eine Meldung.
In der Textdatei stehen folgende Angaben:

go
USE Name
go
EXEC sp_dropuser 'user'
go
EXEC sp_adduser 'user'
GO

GRANT SELECT
ON [dbo].[T_DBO]
TO [user] WITH GRANT OPTION
GO

Die Meldung die ich bekomme lautet:
Finden des Benutzer-Objektes 'user' ist nicht möglich, weil das Objekt nicht vorhanden ist oder Sie nicht die erforderlichen Berechtigungen haben.

P.S.: Ich glaub ich hab mir eine Falsche Definition der Kennwortrichtlinien angeschaut, ich hab noch mal bei MSDN geschaut und bin dort auf dein Zitat gestoßen. Dann wird deins wohl die richtige sein.

[Cre@or]

Ich hab mal folgendes probiert.

USE Name
go

ALTER LOGIN
OFF CHECK_POLICY
GO

Allerdings bekomme ich dann folgende Meldung:

[SQL Native Client]Named Pipes-Provider: Es konnte keine Verbindung zu SQL
Server hergestellt werden [2].
[SQL Native Client]Anmeldungstimeout abgelaufen
[SQL Native Client]Fehler beim Herstellen einer Verbindung zum Server. Bei
einer Verbindung zu SQL Server 2005 kann dieser Fehler dadurch verursacht
werden, dass SQL Server unter den Standardeinstellungen keine
Remoteverbindungen zulässt.

Wenn ich mich jetzt total auf dem Holzweg befinde, dann teilt mir das bitte mit...

mfg Cre@or

P.S.: Hier die Erklärung der MSDN dazu:

CHECK_POLICY = { ON | OFF }
Gilt nur für SQL Server-Anmeldenamen. Gibt an, dass die Windows-Kennwortrichtlinien des Computers, auf dem SQL Server ausgeführt wird, für diesen Anmeldenamen erzwungen werden sollen. Der Standardwert ist ON.

[O. Helper]

Hallo Cre@or,

da ich irgendwie nicht so ganz nachvollziehen kann, was Du da machst, möchte ich noch mal von vorne anfangen.

net start MSSQL$Instanz
copy Datei1.mdf "Ermittelter Pfad zum MS SQL SVR"
copy Datei2.LDF "Ermittelter Pfad zum MS SQL SVR"
osql -U Benutzername -P Passwort -i Datei3.txt

- Da Du eine benannte Instanz hast, muss Du mit diese auch bei der Anmeldung mit "-S SERVER\INSTANZ" angeben; woher soll osql sonst wissen, an welchen Server/Instanz Du Dich anmelden willst.
- Wieso kopierst Du Datenbank-Dateien und was passiert damit im weiteren (z.B. Attach)?
- Was steht in der Datei3.txt; ich nehme mal die SQL Statements?
- Deine Anmeldeversuch mit Management Studio; war das lokal an einem Client oder direkt auf dem Server, wo der MSSQL läuft?
- Hast Du es mittlerweile auch mal mit der Windows-Authenifizierung versucht (Account muss natürlich auch auf dem MSSQL angelegt sein)?

[Cre@or]

Ja, bin grad am Testen.
Hab eine Fehlerquelle meinerseits bereits beheben können.
In der Datei3.txt stehen natürlich SQL Statements.
Also, die Anmeldung erfolgt in meinen Versuchen direkt am Client.
Die Datenbank-Dateien kopiere ich, weil auf die das zu installierende Programm zugreift.
Den Parameter -S usw. gebe ich auch an, hab den bei einem Trockenversuch an Land aus versehen vergessen.
Mein Setup schreibt diesen Parameter natürlich mit in die Bat.
Hoffe hab alle Fragen Ordnungsgemäß beantwortet.
Wie gesagt, mit SQL Servern kenne ich mich nicht allzu gut aus (wenn Überhaupt untere Wissensgrenze) aber ich glaub du hast mir mit deinem letzten Post die Augen geöffnet.
Ich melde mich wenn sich dies bewahrheitet haben sollte, ansonsten aber auch noch mal...

mfg Cre@or

---------------

Hier noch mal der grundsätzliche Aufbau von Datei3.txt:

exec sp_addlogin 'User','User'
go
EXEC sp_attach_db @dbname = N'Daten',
@filename1 = N'Ermittelter Pfad + Datei.mdf',
@filename2 = N'Ermittelter Pfad + Datei.ldf' ;
go
USE Daten
go
EXEC sp_dropuser 'User'
go
EXEC sp_adduser 'User'
GO

GRANT SELECT
ON [dbo].[T_DBO]
TO [User] WITH GRANT OPTION
GO

;DBO's ohne Ende...

quit

[Cre@or]

Da ich ja, wie schon gesagt mich nicht gut mit SQL Servern auskenne, (die Syntax der Statements scheint ja richtig zu sein), drängt sich mir der Gedanke auf, das es daran nicht liegt und mein Code richtig ist. Nur das die Zugriffsberechtigungen etc. des Benutzers für den Server nicht ausreichend sind.
Allerdings konnte ich mit deiner Hilfe bisher trotzdem einen Bug ausbessern.
Ich hatte anfangs vergessen den User-Namen mit in die Datei3.txt einzusetzen und den alten Namen der darin stand, durch den neuen eingegebenen zu ersetzen.

mfg Cre@or

[O. Helper]

Ich würde das Script mal als "fast richtig" bezeichnen.

Wenn wirklich noch

exec sp_addlogin 'User','User'

im Script steht, ist das ja kein PWD, was den Regel entspricht.

Das Ausführen könnte auch durch
EXEC sp_dropuser 'User'
abbrechen, wenn es den User nicht gibt; dann läuft es auf einen Fehler

Ich würde es so gestalten:

[highlight=SQL]USE master
GO
-- SQL Account anlegen
EXEC sp_addlogin 'User', 'IchB1n_EinStrengesPwd'
GO

-- Datenbank anhängen
EXEC sp_attach_db @dbname = N'Daten',
@filename1 = N'Ermittelter Pfad + Datei.mdf',
@filename2 = N'Ermittelter Pfad + Datei.ldf' ;
GO

USE Daten
GO
--Falls User (noch) vorhanden, diesen droppen
IF EXISTS (SELECT 1 FROM sysusers WHERE name = 'User')
EXEC sp_dropuser @name_in_db = 'User'
GO
-- User wieder anlegen
EXEC sp_adduser @loginame = 'User', @name_in_db = 'User'
GO

GRANT SELECT ON dbo.T_DBO TO User --WITH GRANT OPTION
GO[/highlight]

Was auch ein Problem sein könnte ist das ATTACH der Datenbank bzw. das im Rest des Batches auf eine Datenbank verwiesen wird, die es beim Start (bei Kompilation) noch gar nicht gibt.

Versucht mal, Datenbank- und Useranlage in 2 Scripte aufzuteilen und die dann nacheinander auszuführen.

[Cre@or]

Ich werds mal probieren!