I'm confused. What is an ADC? I only know the term as Active Directory Connector, and don't understand how that would help?

Also, it is entirely incorrect, that a WIndows Server added as Member Server into AD is anything like a workstation. It's still a fully featured WIndows Server in it's own right and function. Not every Windows Server in any AD (not even "real" ones) are Domain Controllers. In fact, *no* Windows Server doing real server work should be a DC, and DCs should do nothing else than being a DC, and *only* a DC.

Hi Massimo,

Thanks a lot for your reply. I'm not a real expert in AD so when I was using NT there were PDC (Primary Domain Controller) and ADC (Additional Domain Controler). If all DCs in modern AD are "just AD" and there is dedicated PDC or ADC - OK, I was wrong. That's not a real issue in my understanding.

Regarding "not every Windows Server will be a DC" - sure, agree with you. I would just mention that this exact idea was created when I found that I can't use PAM Application SSO with DSfW as DSfW doesn't provide support for usual AD Schema Extension API so I just can't add needed Classes and SecureLogin can't create needed objects etc. There is another idea from me registered here in the Ideas Portal.

When creating this idea I've been keeping in mind that probably if it is possible to join Windows as a DC into DSfW Domain and give it needed rights to extend Schema - that could be a solution for my issue with PAM. There is a utility adSchema.exe taken from SecureLogin which extend the Schema, it requires a DC (as far as I remember, I've been doing such extension several monts ago).

I know that we can add Windows Server as a Member into DSfW domain but this will be a Workstation join, not the server one. At the same time there a third-party apps which checks the OS and level and requires DC for normal installation. If you try to assign any FSMO Role to the Windows Server joined as a Member (not DC) I think you'll be failed. And if you try to elevate this Member to DC - you'll be failed again as DSfW doesn't support that.

DC should be DC, fully agree with you.

Hi Massimo,

Thanks a lot for your reply. I'm not a real expert in AD so when I was using NT there were PDC (Primary Domain Controller) and ADC (Additional Domain Controler). If all DCs in modern AD are "just AD" and there is dedicated PDC or ADC - OK, I was wrong. That's not a real issue in my understanding.

Regarding "not every Windows Server will be a DC" - sure, agree with you. I would just mention that this exact idea was created when I found that I can't use PAM Application SSO with DSfW as DSfW doesn't provide support for usual AD Schema Extension API so I just can't add needed Classes and SecureLogin can't create needed objects etc. There is another idea from me registered here in the Ideas Portal.

When creating this idea I've been keeping in mind that probably if it is possible to join Windows as a DC into DSfW Domain and give it needed rights to extend Schema - that could be a solution for my issue with PAM. There is a utility adSchema.exe taken from SecureLogin which extend the Schema, it requires a DC (as far as I remember, I've been doing such extension several monts ago).

I know that we can add Windows Server as a Member into DSfW domain but this will be a Workstation join, not the server one. At the same time there a third-party apps which checks the OS and level and requires DC for normal installation. If you try to assign any FSMO Role to the Windows Server joined as a Member (not DC) I think you'll be failed. And if you try to elevate this Member to DC - you'll be failed again as DSfW doesn't support that.

DC should be DC, fully agree with you.

Well, it is obvious that DSfW isn't a "real" AD. It's an emulation, and it's to be expected that not everything workd straight away, or possibly not at all. While the AD schema in DSfW can be altered, it doesn't have the native AD Interface.
But adding a "real" Windows DC really wouldn't help here. Except this plain being impossible, as DSfW of course knows nothing about the necessary synchronization in AD, the same would apply to the extended Schema. It wouldn't sync, and the whole thing would just blow up big time.

If you need a real AD with all possible AD functionality, use IDM (Bundle Edition). 

Massimo,

I have a real expirience with DSfW and in my understanding it's almost the same from the perspective of day-to-day usual activities like network login, GPO etc. It does the same things as AD and does that well enough.

AD in my understanding is just a good-old flat NT domain DB where they put some additional objects describing metadata plus DNS on top of it - and from my experience I can say DSfW works as good as AD if it has needed classes to store the data. At least VMware hasn't been complaining when I've been adding DSfW as an AD server (exactly AD connection, not LDAP).

From perspective of functionality it doesn't matter in my understanding if that's a 'real AD' or its emulator, if it does the job - it's good enough.

Agree with you regarding sync: you're right, there is no clear picture regarding how DSfW will do sync with AD servers. That's an additional thing to think about.

Talking about IDM you meant 'sync your data with normal AD', right? That's not something I'd like to get, I need this ADC as a possible option to extend the schema to make it possible to SecureLogin (which does the magic for PAM, I'm sure you know that) to store it's data. That's all, this is not about users, groups and other things for which we usually uses IDM.