Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

  • Codemeister
  • Registratie: Augustus 2011
  • Laatst online: 27-11 10:44
Hallo allen,

We hebben op werk nieuwe servers voor bepaalde (verschillende!) locaties aangeschaft. Inmiddels is er één systeem uitgeleverd die wij hebben ingericht als simpele server voor o.a. print-taken, lokale software, plus een aantal rollen.

Alle gebruikers hebben een Office 365 account en kunnen, in de oude omgeving, al terecht in hun webmail en (online) Office software.

Wat wij willen is dat er ingelogd kan worden met hun Office 365-account op de werkstations. Met andere woorden: dezelfde logingegevens als waarmee ze nu online inloggen. We hebben gekeken naar Azure en al met diverse tools gespeeld om de synchronisatie van lokale AD>Azure AD en andersom voor elkaar te krijgen, al lukt dat tot nu toe niet echt.

Ik heb een lokale gebruiker aangemaakt en die verschijnt na een sync-update wel netjes op Azure AD, al lukt inloggen niet. De meldingen verschillen van 'aanmeldservices niet beschikbaar' tot 'gebruikersnaam of wachtwoord onjuist'. De logs helpen ons op dit moment niet verder.

Wel is duidelijk dat ons ''non-routable domain' (domain.local) een belemmering vormt, Office 365 werkt namelijk met geverifieerde domeinnamen. Inmiddels hebben we wel een UPN-prefix aangemaakt die verwijst naar ons centrale 365-domein. Alle (verschillende) locaties loggen via de webinterface op dit domein in.

Ik zit nu met de volgende vraag/vragen:
- hoe kunnen we ervoor zorgen dat gebruikers kunnen inloggen met hun bestaande gebruikersnaam en wachtwoord, ervan uitgaande dat bij een wijziging beide kanten (zowel Azure AD als lokale AD) worden bijgewerkt, bijvoorbeeld bij een wachtwoordreset?
- is het noodzakelijk om een werkende domeinnaam te gebruiken of kan dit uiteindelijk een domain.local/domain.intern (non-routable domain) zijn?
- hoe zorgen we ervoor dat de gebruikersnamen en wachtwoorden ook op het lokale AD beschikbaar zijn? Die zijn nu enkel op Office 365 te zien en ook na synchroniseren blijven deze 'ontzichtbaar'

Na het doorspitten van vele topics op de Microsoft community sites hebben we wel al een tool genaamd 'Azure AD Connect' gedownload en gebruikt voor de configuratie.

-

Tot zover mijn verhaal, hopelijk is de situatie helder en kunnen jullie mij/ons op gang helpen. Misschien hebben we iets over het hoofd gezien. Alvast enorm bedankt! :)

  • Semt-x
  • Registratie: September 2002
  • Laatst online: 14:41
Alle vragen die je stelt kun je beantwoorden door een test omgeving op te bouwen en met een test tentant in Azure de omgeving na te bouwen. Jullie omgeving is standaard en voor zover je beschrijft bevat alleen standaard configuratie. Er zijn duizenden implementaties gelijk aan die van jullie.

Je vraag is zo algemeen dat het eigenlijk een consultancy opdracht is, dus of je investeert tijd in deze technologie, of je huurt een consultant in. Op dit forum krijg je wel snel antwoord als je een specifieke technische vraag hebt (en die goed omschrijft).

[ Voor 5% gewijzigd door Semt-x op 21-09-2016 13:54 ]


  • Jazzy
  • Registratie: Juni 2000
  • Nu online

Jazzy

Moderator SSC/PB

Moooooh!

Ben het daar wel een beetje mee eens. Als je na het lezen van alle documentatie nog steeds niet het overzicht hebt dan kun je beter een consultant inhuren die je bij de hand neemt en het allemaal uit gaat leggen.

Even een inhoudelijke reactie dan maar. In alle gevallen is jullie interne AD leidend, gegevens worden dus vanuit AD naar Azure AD gesynchroniseerd en niet andersom (uitgezonderd dan password sync-back en een paar andere attributen). Je eerste uitdaging is dus om een match te maken tussen de AD accounts en de accounts die je al aangemaakt had in Azure AD. Dan kan door middel van soft-matching.

Als je dat voor elkaar hebt dan kun je met dezelfde UPN en wachtwoord inloggen op interne resources en cloud resources. Denk dat je dan al een stuk dichter bij de gewenste situatie bent.

Exchange en Office 365 specialist. Mijn blog.