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

Hi joe,

I have a few comments in response:

[1] ADAM is AD LDS it's stamped all over it in W2k8 server so we just
have to get used to it.

[2] I'm not so sure about the currency of your perf observations; other LDAP
directories have unlimited multimaster now and a lot of work
has been done on scale out and perf. OpenLDAP and Sun Java
DS have good stories in this area.

[3] Agreed sometimes you have to spend money/effort this thread
may have been a case in point.

[4] On lack of management tools "no
surprise" does not cut it IMO if we want to win people over to ADAM.
Try doing a pitch where the "other directory" has a managment
console and all you have is ADSIedit. In W2k8 server the framework is
there with MMC3.0 based Server Role Manager and it's taken serious effort
and bug filing to get AD LDS as a W2k8 server role but at least it is there
in beta
and the basis of a console.

[5] Writing your own sync with perl is not really an option for integrators
trying make a serious offering on a customer case IMO

[6] Overall on windows principals binding and use of userProxy they can be
a real fillip in a windows environment but you could argue that they show
that
ADLDS is windows domain niche, a better story could be had by looking at
Kerberos is AD and possibilities for AD LDS as a KDC for kerberized SSO.
I am really hopeful that Microsoft will pursue that latter.

[7] Sync story also needs effort. IMO DirSync is quite nice, shame
other LDAP vendors did not pick up the draft RFC.

AD LDAP begat AD LDS LDAP but Exchange 4.0 LDAP begat AD LDAP
and that's a long history; if Microsoft want AD LDS to be a an enterprise
LDAP
competitor they need to show their colours IMO - I'm really hoping they will
as I believe they have a good story that could be much better if effort were
available.

cheers
Lee Flight

"Joe Richards [MVP]" <humorexpress@xxxxxxxxxxx> wrote in message
news:eeSIIL5oHHA.1776@xxxxxxxxxxxxxxxxxxxxxxx
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: ADAM Load balancing
    ... of LDAP ping, however for bought-in application you will need some form ... Microsoft NLB will take care of server availability and give you some ... offer a wide range of load balancing options. ... because of ADAM being derived from AD which has a DC locator mechanism. ...
    (microsoft.public.windows.server.active_directory)
  • Re: trace logger for ADAM - "Windows NT Active Directory Service"
    ... I do not think it's disabled as such in ADAM but broken. ... Imagine one LDAP server with several dozens of LDAP applications. ... Active Directory provides a similar trace logger, ...
    (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)
Loading