Azure AD Domain Services

  • 159 Views
  • Last Post 20 October 2015
slavickp posted this 14 October 2015

https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-features/
This is unexpected. I thought we’re entering post-AD era.
Did you come across cases where the AAD DS could help? I wonder what those are
Regards
Slav
MCM-AD
Sent from Surface

Order By: Standard | Newest | Votes
bdesmond posted this 14 October 2015

The idea is that it enables you to be able to forklift workloads to Azure IaaS that are still dependent on AD DS to function. Think legacy applications that

require LDAP or domain membership or the like to function.

 



Thanks,

Brian Desmond

brian@xxxxxxxxxxxxxxxx

 

w – 312.625.1438 | c – 312.731.3132



 

show

darren posted this 14 October 2015

What I’m curious about with this, is how authentication works with this thing, assuming you’re already federating on-prem AD to Azure AD (or even if you’re

not). Does this new thing store secrets? Does it require Azure AD to store secrets? Do they relate at all to on-prem AD, etc.

 

Will be interesting to see how it works.

 

Darren

 

show

bdesmond posted this 14 October 2015

It relies on hash sync to your Azure AD tenant.



 



Thanks,

Brian Desmond

brian@xxxxxxxxxxxxxxxx

 

w – 312.625.1438 | c – 312.731.3132



 

show

gkirkpatrick posted this 14 October 2015

“Post –AD era” in the same way we’ve entered the post-mainframe era. Or the post-Cobol era for that matter. Ubiquitous infrastructure

retires slowly and asymptotically.

 

-g

 

show

Tony posted this 14 October 2015

>> asymptotically




I suspect I was not the only one reaching for the dictionary for that one. 😊




I think LDAP support is going to be the primary value-add for Azure AD Domain Services.  Lots of LDAP still out there. "I'm not dead!"

 

Tony









show

ZJORZ posted this 14 October 2015

There is a 1-to-1 relation between an Azure Directory and an Azure AD domain. In terms of objects the contents is the same, it is just another different representation and interface So whatever you sync into an Azure Directory becomes automagically available in the Azure AD domain Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 26.26.62.80 Description: Description: Description: Description: Think Green 

show

kevinrjames posted this 14 October 2015

So how do OU structures and custom schema attributes work – or do they?  It sounds like a AAD bolt on GP’s with machine accounts and LDAP API’s  /kj 

show

darren posted this 14 October 2015

Yea, it will be interesting to see what this actually looks like from a tooling perspective as well. The description of one builtin GPO for computer and user

containers is something I had heard about earlier and it seemed a bit wonky. Also, I believe this service is only exposed to workloads running in Azure IaaS—at least, that’s the way it was originally described to me. So, you can’t turn this on for external

consumption.

 

The use cases seem a bit sketchy to me at the moment, but we’ll see.

 

Darren

 

 

 

show

eccoleman posted this 14 October 2015

Sounds to me just an opening of the protocols (LDAP, Kerb5, NTLM, etc.) to what’s already in Azure AD.  My assumption is that this is only visible to Azure tenant

hosts?  What about consuming security logs from said authentications and LDAP queries?

 

--

Erik Coleman

Senior Manager, Enterprise Systems

Technology Services at Illinois

University of Illinois at Urbana-Champaign

 

 

 

show

gkirkpatrick posted this 14 October 2015

That’s what I get for paying attention in math class that one time.

J

 

I agree… most apps just need that little bit of LDAP support. A good percentage need the whole Windows client Kerb/NTLM stack as well.

 

-g

 

show

kevinrjames posted this 14 October 2015

Oh joy. Another layer of murkiness to befuddle the masses.  Would love to hear first-hand when someone previews this third AD ‘like’ Azure service offering.  /kj 

show

gkirkpatrick posted this 14 October 2015

>>

The use cases seem a bit sketchy to me at the moment, but we’ll see.

 

I don’t think it’s any more complicated than being able to take on-prem Windows-integrated apps and run them on Azure VMs. Think of

all those IIS apps that use integrated authN or query group memberships…

 

-g

 

show

kool posted this 14 October 2015

This sounds like an automated version of creating a replica DC hosted in Azure. The big differences seem to be no VPN back to corpnet nor manual maintenance required.

What’s not clear is if the Azure AD DC will use the same LDAP FQDN and DNS FQDN as your on-premise AD. Do SPNs get replicated and just work? Ditto for constrained delegation. Another question, does this count as a DR/GR DC? I doubt it as it doesn’t replicate

the exact contents of your on-prem DCs.

 

As usual, more questions than answers.

 

    Eric

 

show

bdesmond posted this 14 October 2015

It’s a different domain name that you pick and bind to your AAD tenant. You’ll need to join machines directly to it that are running in IaaS. This is not a

replica of your existing AD domain.

 



Thanks,

Brian Desmond

brian@xxxxxxxxxxxxxxxx

 

w – 312.625.1438 | c – 312.731.3132



 

show

RickSheikh posted this 14 October 2015

This 10min talk might answer some of the questions, looks like the domain name can match the onprem AD if needed.

show

michael1 posted this 15 October 2015

Funny.

J

 

As I know you suggest – most of my enterprise clients still rely on mainframes and those mainframes run huge amounts of COBOL.

 

My enterprise clients have no plans or intentions to change those things anytime soon.

 

I think that when I decide to “retire” in a decade or so, I will retire as a COBOL programmer.

J Giving me as much work as I might desire.

J

 

show

danj posted this 15 October 2015

Number of systems is asymptotic, cost to get MSFT support the remaining ones is exponential :) see NT 4.0…

 

The MSFT rep we saw in March was getting very excited about this, it’s obviously taken them a while to get to preview (he said June initially). They needed a

complete rewrite of AD Sync to get it working as I understand.

 

I see DR/standby as a prime use case initially.

 

Dan

 

 

show

darren posted this 20 October 2015

Ok. Got this up and running and posted a walkthrough video:

href="
/>
 

Feedback/questions?

 

Thanks!

 

Darren

 

show

jeremyts posted this 20 October 2015

Nice one Darren. Thank you for that

J

 

show

href="
/>
 

Feedback/questions?

 

Thanks!

 

Darren

 





From:

activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Dan Johnson


Sent: Thursday, October 15, 2015 3:05 AM


To: activedir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Azure AD Domain Services





 

Number of systems is asymptotic, cost to get MSFT support the remaining ones is exponential :) see NT 4.0…

 

The MSFT rep we saw in March was getting very excited about this, it’s obviously taken them a while to get to preview (he said June initially).

They needed a complete rewrite of AD Sync to get it working as I understand.



 

I see DR/standby as a prime use case initially.

 

Dan

 

 





From:

activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Gil Kirkpatrick (gilkirkpatrick.com)


Sent: 14 October 2015 22:55


To: activedir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Azure AD Domain Services





 

That’s what I get for paying attention in math class that one time.

J

 

I agree… most apps just need that little bit of LDAP support. A good percentage need the whole Windows client Kerb/NTLM stack as well.

 

-g

 





From:

activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Tony Murray


Sent: Thursday, 15 October 2015 7:47 AM


To: activedir@xxxxxxxxxxxxxxxx


Subject: Re: [ActiveDir] Azure AD Domain Services





 



>>

asymptotically

I suspect I was not the only one reaching for the dictionary for that one.

😊

I think LDAP support is going to be the primary value-add for Azure AD Domain Services.  Lots of LDAP still out there. "I'm not dead!"

 

Tony














From:

activedir-owner@xxxxxxxxxxxxxxxx <activedir-owner@xxxxxxxxxxxxxxxx> on behalf of Gil Kirkpatrick (gilkirkpatrick.com) <gil@xxxxxxxxxxxxxxxx>


Sent: Thursday, 15 October 2015 9:39 a.m.


To: activedir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Azure AD Domain Services





 









“Post –AD era” in the same way we’ve entered the post-mainframe era. Or the post-Cobol era for that matter. Ubiquitous infrastructure retires slowly

and asymptotically.

 

-g

 





From:

activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Brian Desmond


Sent: Thursday, 15 October 2015 7:04 AM


To: activedir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Azure AD Domain Services





 

The idea is that it enables you to be able to forklift workloads to Azure IaaS that are still dependent on AD DS to function. Think legacy

applications that require LDAP or domain membership or the like to function.



 



Thanks,

Brian Desmond

brian@xxxxxxxxxxxxxxxx

 

w – 312.625.1438 | c – 312.731.3132



 





From:

activedir-owner@xxxxxxxxxxxxxxxx [mailto:activedir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of sl@xxxxxxxxxxxxxxxx


Sent: Wednesday, October 14, 2015 2:42 PM


To: activedir@xxxxxxxxxxxxxxxx


Subject: [ActiveDir] Azure AD Domain Services





 





https://azure.microsoft.com/en-us/documentation/articles/active-directory-ds-features/





 





This is unexpected. I thought we’re entering post-AD era.







 





Did you come across cases where the AAD DS could help? I wonder what those are





 





Regards





 





Slav





 





MCM-AD





 







 





Sent from Surface





 

Close