Password sync from AD DS to AD LDS

  • 82 Views
  • Last Post 08 March 2017
Biju_Babu posted this 03 March 2017

Hello,   I am planning to migrate users from an AD DS Forest to AD LDS instance. Is there any way to sync the existing passwords across?

  I could find FIM as possible option to sync the password changes, is that the only way?    

Regards, Biju
.

Order By: Standard | Newest | Votes
cduers posted this 03 March 2017

PCNS/FIM is the best way.

Christopher Duers
XL Catlin, Identity and Security
203-979-3914
chris.duers@xxxxxxxxxxxxxxxx

On Mar 3, 2017, at 10:22 AM, Biju Babu <>> wrote:

Hello,

I am planning to migrate users from an AD DS Forest to AD LDS instance. Is there any way to sync the existing passwords across?

I could find FIM as possible option to sync the password changes, is that the only way?


Regards,
Biju
.

show

joe posted this 03 March 2017

We do this in our org to support a specific scenario and use PCNS/FIM to do it. The key thing here is that passwords are synced when they change so you'll need to ensure all the target users change their passwords.
You can't recover the existing passwords without hacking tools.
Joe K.


show

m4ppy posted this 03 March 2017

Have a look at the pes option in ADMT

Regards

Chris Mapp, Global Active Directory - Team Leader
Marsh & McLennan Companies
Global Technology Infrastructure (MGTI) | Centralized Operations
No 4 St Paul’s Square, Old Hall Street, Liverpool, L3 9SJ
Tel +44 151 242 7029 | Mobile +44 7824 548 873 | chris.mapp@xxxxxxxxxxxxxxxx
www.mmc.com

show

kevinrjames posted this 03 March 2017

Looked into using proxy auth instead?  /kj 

show

Biju_Babu posted this 06 March 2017

This was my first thought, but I couldn’t get ADMT to connect to AD LDS instance, I couldn’t find any documentation either. Have you tried ADMT against AD LDS successfully?


Regards,
Biju

My working hours are from 1:00 PM to 9:00 PM IST (1:30 AM CST to 9:30 AM CST)

show

Biju_Babu posted this 06 March 2017

Thanks Kevin, I wasn’t planning to use that.



 

@Joe, @Chris – thank you, will try PCNS/FIM.





 

Regards,

Biju







My working hours are from 1:00 PM to 9:00 PM IST (1:30 AM CST to 9:30 AM CST)

 

 



 

show

bdesmond posted this 06 March 2017

ADMT does not work with AD LDS.

Thanks,
Brian Desmond

(w) 312.625.1438 | (c) 312.731.3132

show

barkills posted this 06 March 2017

I think you’ve gotten the following answer to your question:

No, unless you run a password crack and write your own code to scoop up those cracked passwords and send them to AD LDS.

 

You’ve gotten a workaround of using PCNS, but that does not actually meet your requirements of using the existing password. But your follow-up email on that workaround

suggests you think it might be workable.

You’ve also gotten a workaround suggestion to use AD LDS’s proxy user objects so you don’t need to migrate the password.

 

I wonder why you are migrating to AD LDS and what the actual scenario & goal are, because it feels like you are asking for help but not actually giving us the

underlying problem to solve.

 

Brian

 

show

kevinrjames posted this 06 March 2017

But will the Password Export Server allow import into an ADLDS? - something I've never tried.


/kj

show

chriss3 posted this 06 March 2017

Nope. PES works in that way it extracts the NTOWF hash, and then import the NTOWF hash again (without having it being NTOWF:ed again) - this requires SAM. There is no such functionality in SAM or SAMADAM that ports over some SAM functionality to ADAM/ADLDS so far I know.

show

Biju_Babu posted this 06 March 2017

Sure Brian. I thought I would spare the story

J

 

I have got 2 – 3  independent forests (nothing fancy, few hundred to few thousand users and 2 DCs per forest) solely set up to act as directory repository for some external

applications. The provisioning and stuff happens via thirdparty provisioning tools. Earlier those were in some kind of LDAP directory and its moved to these independent forests as part of lifecycle and unfortunately I was late to the party.

It’s a pain to manage those forests IMHO and I am hearing that there could be few in the pipeline. And the simplest solution I could think of is using ADLDS and make sure this

technology is operationalized with the ops team.

 

Being it external application and all, password change communication etc.. could be pain so I was looking for a transparent solution. Good news is that, password do expire

for those accounts and that’s where I could use FIM/PCNS (Though I never used FIM before, so it’s going to be fun..).

 

Hope it helps. I am very much open to other suggestions. Thank you!!.  

 



 

 

Regards,

Biju







 

 



 

show

dddugan posted this 06 March 2017

Maybe consider Azure AD B2B or B2C….

 

show

bdesmond posted this 06 March 2017

No, it won't work.

Thanks,
Brian Desmond

(w) 312.625.1438 | (c) 312.731.3132

show

bdesmond posted this 06 March 2017

+1. If you’re not going that route, though, I’m not sure how managing a few AD LDS servers will be any less work than managing

a few domain controllers.


 



Thanks,

Brian Desmond

 

(w) 312.625.1438 | (c) 312.731.3132



 

show

joe posted this 07 March 2017

Adding to what the others have said here, AD LDS is not a great identity store. It missing all kinds of features such as flexible password policies and dictionary word blocking that will never be added to it but are becoming much more commonplace requirements. There also isn't a great way to add MFA to it (although you can probably cobble something together). And like Brian said, it isn't really that different from running a few DCs. Like Darin suggested, Azure AD B2B or B2C might be a good idea although if you just want an identity store and don't want or need to allow users to bring their own identities, you could just use Azure AD straight up for this. I think I'd likely take that route.
The issue with Azure AD is that a lot of the fancier features are associated with premium and paying those costs for external users (or figuring out how to work that with your EA) might not make a lot of sense. At the same time, it is really hard for me to be excited about you spinning up an AD/LDS for this. We've had something like this running for around 6 years now and are actively looking for a way out.
Joe K.


show

DonH posted this 07 March 2017

AD LDS was not intended to be an identity store.  More specifically, it was intended to NOT be an identity store.  It’s supposed to be a resource store for directory-style resources that uses an existing AD domain as its identity store.  Resource managers get the full flexibility of directory resources without the hassle of managing their own identity store or dealing with the pig-headed stodginess of domain administrators confronted with schema updates.  Domain administrators get to keep their domains nice and clean without the schema bloat, object bloat, and 2am panicked calls from resource managers that having application data shoved into the identity store brings. Don “Well, it seemed like a good idea at the time” Hacherl 

show

joe posted this 07 March 2017

I believe what you are saying Don. The problem is that AD LDS has a bunch of very useful identity store features such a bindable objects, bind proxies and a pretty robust system for group management and "token calculation". These features encouraged its use as an identity store.
And it is fairly close to being a decent identity store. The coupling of the password features to the OS and the lack of separate password policies were the two killer shortcomings in my mind.
Joe K.

show

Biju_Babu posted this 07 March 2017

Thanks, let me look into it.

 



 

Regards,

Biju







 

 



 

show

DonH posted this 08 March 2017

Yeah, and I’ve used a wrench as a hammer before.  It was heavy, convenient, and fairly close to being a decent hammer.  Wasn’t quite what the designer had in mind, though. Don 

show

Close