[win32] Windows Naam resolutie

[Wim-Bart]

Volgende situatie:

Computer:
- DNS server ingesteld
- WINS ingesteld
- HOSTS [gevuld of leeg]
- LMHOSTS [gevuld of leeg]

In de DNS staan records met de naam:
domeinnaam.mijndomein.local A IP nummer X
domeinnaam.mijndomen.nl Zone

In de WINS staan een records
domeinnaam <1C> IP nummer Y
domeinnaam <20> IP nummer Y

IP nummer Y en IP nummer X zijn verschillend.

DNS is niet aan te passen omdat er meerdere andere applicaties domeinnaam.mijndomein.local gebruiken. Deze doen dan ook een GetHostByName() call om het IP nummer te achterhalen.

Nu is domeinnaam ook de naam van een getrust NT4 domein. Lekker duidelijk dus dat ze in de DNS hiermee hebben lopen klooien.

Wat ik nu wil is dat ik met een functie of meerdere functies IP nummer Y uit WINS of LMHOSTS krijg in plaats van de DNS naam. Ik wil dus DNS en HOSTS niet meenemen bij adres resolving.

Iemand een idee?

[Verwijderd]

wim-bart schreef op vrijdag 09 juni 2006 @ 00:47:

Los van hoe dit probleem heeft kunnen ontstaan.

DNS/WINS-resolutie is zwart-op-wit niet meer dan het koppelen van een naam aan een ip-adres.

Maak een alias aan voor die server en het scheelt je een hoop werk.

[Wim-Bart]

Verwijderd schreef op vrijdag 09 juni 2006 @ 22:35:
[...]

Los van hoe dit probleem heeft kunnen ontstaan.

DNS/WINS-resolutie is zwart-op-wit niet meer dan het koppelen van een naam aan een ip-adres.

Maak een alias aan voor die server en het scheelt je een hoop werk.

Was het maar zo simpel. De klant waar het voor is werkt met verschillende eigen autonome regiogebieden. Wij zijn één een van deze gebieden. Beheer DNS geschied vanuit een centrale plaats waar een "expert" (denk er het mijne van) een aantal CNAME's in de root van het domein heeft aangemaakt, deze wijzen naar een Linux machine (tja, weer dat Linux). De DNS ziet er als volgt uit.


domein.local
naam1 CNAME linux.domein.local
naam2 CNAME linux.domein.local
naam3 CNAME linux.domein.local

Daarnaast is er een dns domein:
domein.nl
Met daarin de volgende zones:
naam1.domein.nl
naam2.domein.nl
naam3.domein.nl

Onder deze zones staan machines:
naam1.domein.nl
pdcvannaam1.naam1.domein.nl A 1.1.1.1
bdc1vannaam1.naam1.domein.nl A 1.1.1.2
bdcxvannaam1.naam1.domein.nl A 1.1.y.x
server1vannaam1.naam1.domein.nl A 1.1.1.4
serverxvannaam1.naam1.domein.nl A 1.1.y.x

Dit geldt ook voor de andere zones naam2 en naam3.

domein.local is een active directory domein. naam1.domein.nl t/m naam3.domein.nl zijn Windows NT 4 domeinen. Deze zijn via een 2-way trust getrust met het AD domein tijdens de migratie en worden afgebouwd.

Daarnaast staat er in onze regio een WINS server. Deze bevat alle gegevens over onze NT4 domeinen en onze Windows 2003 servers binnen ONZE regio.

Gebruikers en globale groepen zijn gekoppeld via SID history. Wat wil zeggen dat SIDS van de NT4 domeinen toegevoegd zijn aan AD accounts en AD groepen. Dit is een geven waar we helaas zolang niet alle NT4 meuk is opgeruimd om heen kunnen.

Nu komt het voor (dus niet "kan het voorkomen") dat op alle NT4 resources SIDS van gebruikers en groepen staan van de NT 4 domeinen. Daarnaast staan er op de Windows 2003 resources zowel SIDS van de AD gebruikers en groepen als ook SIDS van de NT4 gebruikers en groepen. Deze situatie bied de volgende voordelen (ook nadelen):

1) Gemigreerde gebruikers hebben door SID History toegang (via Access Token) rechten op nog niet gemigreerde resources in hun oude domein.
2) Nog niet gemigreerde gebruikers hebben toegang tot reeds gemigreerde resources.

Om de rechten op de AD kant (Windows 2003) enigssinds te kunnen managen en oude nog niet gemigreerde NETBIOS over TCP/IP applicaties te gebruiken hebben we een WINS server draaien in de AD omgeving. Op zich werkt dit goed. Helaas tot een onverlaat dus de naamX.domein.local CNAMES had aangemaakt waar wij geen controle over hebben. Het probleem met de NETBIOS applicaties is inmiddels opgelost maar nog niet met onze rechten management tooling waar druk aan wordt geprogrammeerd.

Deze tooling werkt als volgt:
1) Lees de ACL van een resource (file/folder/share).
2) Verwerk iedere ACE.

Wanneer je de standaard Windows API's gebruikt zie je bij 2 verschillende SIDS dat door SID history de naam dubbel wordt geresolved naar ADDOMEIN\User cq. ADDOMEIN\Groep terwijl dit moet zijn ADDOMEIN\User of ADDOMEIN\Groep en NTDOMEIN\User of NTDOMEIN\Groep.

Om dit op te lossen nemen we de SID uit de ACE en hakken de RID er af en maken er een DOMEIN-SID van. Hierbij vragen we netjes de domeinnaam op behorende bij deze DOMEIN SID wat ook goed gaat. Wanneer we nu echter de API call's dsGetDCname, GetDCName of GetAnyDCName gebruiken dan krijgen we een error terug welke aangeeft dat het NT 4 domein controller niet geresolved kan worden. Doen wij dit voor NT4 domeinen waarvan geen CNAME records in domein.local staan gaat dit wel goed.

Wanneer we een GetHostByName doen krijgen we het ip adres terug van de linux.domein.local waardoor we er achter kwamen dat daar het probleem lag. Nu zijn er een aantal methoden waaronder etc/hosts aan te passen, maar dat is geen oplossing omdat dat andere problemen met zich meebrengt. De enige oplossing is dus een soort GetHostByName die alleen WINS of LMHOSTS gebruikt. Maar hoe dat te doen?

[Verwijderd]

wim-bart schreef op zondag 11 juni 2006 @ 14:47:
[...]
Wanneer we een GetHostByName doen krijgen we het ip adres terug van de linux.domein.local waardoor we er achter kwamen dat daar het probleem lag. Nu zijn er een aantal methoden waaronder etc/hosts aan te passen, maar dat is geen oplossing omdat dat andere problemen met zich meebrengt. De enige oplossing is dus een soort GetHostByName die alleen WINS of LMHOSTS gebruikt. Maar hoe dat te doen?

Volgens diverse bronnen wordt eerst WINS geraadpleegd en dan pas DNS Bij jou is dat dus duidelijk niet het geval?

1. Local cache
2. WINS server (primary then secondary, two times).
3. Broadcast
4. Lmhosts file
5. Hosts file
6. DNS
Windows 200x WINS


• Check to see if it is the local machine name.
• Check its cache of remote names. Any name that is resolved is placed in a cache where it will remain for 10 minutes.
• Try the WINS Server.
• Try broadcasting.
• Check the LMHOSTS file, if the system is configured to use the LMHOSTS file.
• Try the HOSTS file and then a DNS, if so configured.
NetBIOS over TCP/IP Name Resolution and WINS

Kun je het gedeelte achter de host niet (automatisch) als suffix erachter plakken?
link (Het gaat even om het idee, er wordt in de link gesproken over DSN, maar het principe maakt volgens mij niets uit.)

[elevator]

Resolving order kan je instellen als zogenaamd node-type, dit kan dmv. een DHCP server overriden worden waardoor je dus idd deze problemen kan hebben

NT4 werkt niet met DNS domain names dus die trust en NT4 domain names hebben op zich niet zo veel met elkaar te maken wat betreft het Windows ontwerp - ik begrijp met deze informatie die keuze dus ook niet helemaal, maar goed

Ik weet verder niet of je dit wel opgelost krijgt - volgens mij gebeurt het resolven van die domain name door de lagere API call die je securitydescriptor zet en niet door jouw applicatie, maar dat is allemaal wat vervaagd

[Wim-Bart]

Verwijderd schreef op zondag 11 juni 2006 @ 21:02:
[...]
Kun je het gedeelte achter de host niet (automatisch) als suffix erachter plakken?

Dat werkt goed. Alleen is het probleem dat ik de suffix in het slechtste geval niet weet, althans mijn applicatie. Ik heb overigens het idee gehad om de DNS serach suffix lijst te gebruiken als alternatief, maar de applicatie moet ook op systemen draaien welke die lijst niet hebben.

[Verwijderd]

wim-bart schreef op maandag 12 juni 2006 @ 12:53:
[...]


Dat werkt goed. Alleen is het probleem dat ik de suffix in het slechtste geval niet weet

Hoe groot is die kans?

wim-bart schreef op maandag 12 juni 2006 @ 12:53:
...
, althans mijn applicatie.

Ik heb overigens het idee gehad om de DNS serach suffix lijst te gebruiken als alternatief, maar de applicatie moet ook op systemen draaien welke die lijst niet hebben.