Re: Keep ADAM proxies up-to-date through LDIFDE

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

You can blame marketing for that rename. None of us who love and actually use ADAM intend to call it anything other than ADAM.

I don't think MSFT is just dabbling with LDAP though. The core of the windows network relies on LDAP, I know of no other OS, in fact, that relies so much on LDAP. The integration of ADAM into a domain and the ability to use domain security principals blows a lot of the other directory implementations out of the water where you have to have individual IDs on every LDAP directory. Also just in terms of directory replication, multimastering, etc Microsoft is blowing the other directory vendors out of the water. I used to work for a very large org that used most of the LDAP services out there and I have to say that AD out performed them all in most of the key areas. Some of the directories had some functionality that I wish AD had like multiple RDN attributes on an object or ability to properly log what was being done against the directory but overall, AD smoked them all.

I recall back in 2002 or so we were populating the Exchange GAL info into AD, this consisted of approximately 40 or so attributes between Exchange the company specific GAL entries. This info had to be replicated to my ~400 DCs across the world across lines as slow as 56k. We also at the same time had to update a single flag attribute in an iPlanet directory which sat on 4 big UNIX servers in a single rack of a single datacenter on a single physical switch. We wanted to spin up slow so that we didn't overwhelm AD, but as I watched the updated I told them to speed up more and more the number of records per hour being sent. We got up to about 1500 records per hour and the iPlanet people asked us to slow down because the iPlanet servers were churning too much. My AD was practically idling.

I didn't read the thread in detail, but what I picked up was that adamsync doesn't do all of the required syncing needs... fine... use IIFP or MIIS, spend some money. If not that, get LDSU or some other more lightweight syncing product... i.e. spend some money. If not that, build something in perl or find some open source or other free syncing tool. Microsoft has always been bad around utilities/tools, nothing new there. They build underlying infrastructure and then let people build on top of it. The lack of management tools for ADAM other than the most basic is no surprise and is by design. As they will tell you themselves, it isn't like AD which has a pretty fixed use, ADAM could be used for anything and tools that really work for the common people tend to need to be specific to the use. They could build an amazing framework for managing it but why? This is a great area for third parties, etc. MSFT made it pretty open in terms of programmatic ability to manipulate. So manipulate it.

LDIFDE in itself is a sucky tool to be doing any major work in any directory, certainly I wouldn't consider it for a constantly running sync tool. It is a simple import/export tool and the formatting of the data sucks but MSFT is also limited as there are standards that they have to adhere to there. I would use my adfind/admod for syncing AD and ADAM before I would use LDIFDE. I don't have to follow and standards with those other than what I choose to follow. But if I really needed something like that and nothing available fit, I would probably just write a sync in perl and be done with it. Writing that code will help you understand how difficult it is to write very flexible code that can fit any possible model someone might want to throw at it but on the positive side, you don't have to write it to be that flexible as you know your requirements. But if you keep that in mind you will see why others don't just do it and hand it out for free and it be super easy to use. It just isn't a likely scenario to line all of those ducks up, certainly not for free.

If you talk to the DS Dev guys you will hear this... "We have built you a replicating store accessible via LDAP that is intelligent enough to understand domain security principals, use it as you wish...".

How great is it that you can use userProxies at all? What other directories out there will let you do real SSO like that? Usually you have to copy the whole userid between directories and then syncing becomes a whole other level of important or else passwords go out of sync and life is extremely painful. Again, been there, worked in a company that had LDAP directories on Mainframes and DEC Minis and UNIX machines and LINUX machines and Windows machines (besides AD/ADAM). I can tell you that company is collapsing all directories into AD and ADAM because of the massive number of benefits of doing so.

joe



--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm


Nicolouw M. Kruger via WinServerKB.com wrote:
Hi

Paul Williams [MVP] wrote:
working there. There's definately a need for it, and many people don't want the cost, complexity or weight of MIIS (or IIFP) when they're only synchronising subsets of their AD DS to other LDAP directories or

As a customer-based consultant I must say the support for ADAM and ADAMsync
is basically limited to these forums and people like Lee, Dimitri, etc.
Without them ADAM will not be going anywhere. I have posted elsewhere on this
forum that MS must get their ducks sorted with re ADAM resources, knowledge
base, etc. If not then I will be forced to on my next customer engagement
recommend alternative LDAP solutions - that is not a threat its just the way
life works. This ADAM can really fly in the App/AZ space but then MS needs to
get serious and stop dabbling with LDAP. Instead they have decided to rename
it to something ridiculous like "Active Directory Lightweight Directory
Services" (ADLDS), ouch. That kind of says it - to rename a "lekker" (really
nice in my language) name like ADAM into ADLDS ;)

Nicolouw

.

Relevant Pages

  • Re: Keep ADAM proxies up-to-date through LDIFDE
    ... ADAM is AD LDS it's stamped all over it in W2k8 server so we just ... I'm not so sure about the currency of your perf observations; other LDAP ... surprise" does not cut it IMO if we want to win people over to ADAM. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM Bind Redirection question
    ... ADAM relies on windows auth mechanisms, it does not keep an ldap connection ... Windows domain in order to enable proxy binds. ... the idea here is to use AD secure binding with Active ...
    (microsoft.public.windows.server.active_directory)
  • Re: Virtual List View functionality in ADAM and Outlook
    ... point to ADAM from outlook using generic LDAP then I at least have a solution ... As for VLV- ADAM does support it. ... continue to try to manage this volume of information with MIIS? ... but my understanding of VLV's is that the client has to ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD or ADAM as a user database
    ... SQL system. ... ADAM with SSL will ... Learning how to design LDAP schema isn't hard as there isn't too much to it, ...
    (microsoft.public.windows.server.active_directory)
  • Re: Virtual List View functionality in ADAM and Outlook
    ... I guess you can configure multiple LDAP services, pointing to the same ADAM ... If I can somehow do the same thing using Outlook/ADAM, ...
    (microsoft.public.windows.server.active_directory)