[2003] IIS lokale useraccounts gebruiken ipv AD ?

[Mephix]

Windows 2003 std, is member server en staat in DMZ. Hierop staat IIS met een FTP server. Wanneer ik gebruikers lokaal aanmaak, kan ik alleen inloggen met <servernaam>\<username>.

Doe ik dat niet, dan worden mijn login gegevens gechecked tegen de AD, en daar staan die FTP users dus niet in.

De server kan niet uit het domein, omdat er ook websites op draaien, die met windows auth werken. De ftp users in de AD zetten heeft ook niet echt de voorkeur

Wat ik dus wil is dat de IIS mijn login gegevens standaard checked tegen de lokale user accounts, niet tegen die van de AD. Of misschien eerst tegen de AD, user niet gevonden ? Dan alsnog kijken in lokale accounts. In ieder geval zonder de servernaam voor de loginnaam te hoeven tikken.

Alternatief wat ik al geprobeerd heb:
----
Wanneer ik klanten via een website doorverwijs naar ftp://<servernaam>\<username>:<password>@ftp.server.nl dan werkt dat min of meer, alleen als je dat doet met een document.location.href (JS), of met een <? header: Location= ... ?> of met een <% Response.Redirect(....) %> dan gebeuren er 2 dingen:

- De ftp server logt niet meer 'door' naar de homedirectory van de user (wat IIS normaal gesproken wel doet, wanneer loginnaam gelijk is aan een mapnaam)
- Je browser maakt geen gebruik meer van de Windows Verkenner-achtige layout voor het browsen op de FTP server, maar gebruikt de ouderwetse manier (beetje zoals een open-dir op een apache server zeg maar).

Als je dezelfde url (dus ftp://server\user:pass@ftp) in je browser intikt, dan werken bovenstaande zaken wel gewoon... erg maf!

[alt-92]

Mephix schreef op maandag 10 oktober 2005 @ 16:39:
In ieder geval zonder de servernaam voor de loginnaam te hoeven tikken.

Denk dat je dat niet zal lukken.
qua authenticatie heb je feitelijk 2 domains, 1 AD en 1 lokale SAM.
Je zal dus altijd een verschil moeten aangeven, hetzij door user@UPN, domain\user of machinenaam\user.

Maar wat is er mis met het aanmaken van accounts in je AD?
Dichtgetimmerde OU met welgemikte policies en gaan met die banaan.

[Question Mark]

Mephix schreef op maandag 10 oktober 2005 @ 16:39:
Wat ik dus wil is dat de IIS mijn login gegevens standaard checked tegen de lokale user accounts, niet tegen die van de AD. Of misschien eerst tegen de AD, user niet gevonden ? Dan alsnog kijken in lokale accounts. In ieder geval zonder de servernaam voor de loginnaam te hoeven tikken.

FTP Service's DefaultLogonDomain Not Available in MMC

Run Adsutil.vbs from a command prompt, using the appropriate syntax below (depending on whether you want to set DefaultLogonDomain for all FTP sites, just the default FTP site, or other sites):
• To set DefaultLogonDomain for all FTP sites, run the following command:
adsutil set msftpsvc/DefaultLogonDomain "DomainName"
• To set DefaultLogonDomain for only the default FTP site, run the following command:
adsutil set msftpsvc/1/DefaultLogonDomain "DomainName"

Ipv DomainName je Computername invullen, en users worden standaard gevalideerd tegen de lokale SAM.

BackSlash32 schreef op maandag 10 oktober 2005 @ 18:02:
[...]
Je zal dus altijd een verschil moeten aangeven, hetzij door user@UPN, domain\user of machinenaam\user.

Niet met bovenstaande aanpassing. Ik heb dit toe moeten passen met een of andere gare AS400. Deze kon geen username langer dan 14 karakters meegeven. Handig als domainname\username al boven de 14 karakters uitkomt Door nu de defaultdomainname al op te geven, volstond alleen de username al, om alsnog tegen het domein gevalideerd te worden.

[ Voor 26% gewijzigd door Question Mark op 10-10-2005 19:36 ]

[alt-92]

Wel een mooie oplossing om dat van te voren al mee te geven inderdaad

*bookmarkt*

[ Voor 9% gewijzigd door alt-92 op 10-10-2005 20:23 ]

[Mephix]

Dat is ook precies wat ik zocht.. de klanten de servernaam in laten vullen, gevolgd door hun username is gewoon niet netjes.. op deze manier kan ik dus de users wel lokaal aanmaken (wat middels een aanmeld-website gebeurd en vervolgens via een tooltje wat de users/mappen en rechten maakt) en we're done.

Ik heb dat vbs tooltje nog niet geprobeerd, maar ik ga er ff vanuit dat het werkt Eerstvolgende keer dat ik bij die klant zit zullen we het zien!

Thnx!!!