|
The
application (SAP enterprise portal) does an LDAP bind to authenticate the
user. I do not know at this point what (if any) encryption options are
available.
Proxy objects
only work for the domain the ADAM server is in, or other domains with a 2-way
trust.
Here's the
scenario:
We have one
domain (lets call it INTRANET) that contains our company employees. We have
another domain (lets call it EXTRANET) that contains users for our existing
business partner web-based Internet applications. The two domains do not
currently, and will never in the foreseeable future, trust each
other.
We will be
deploying one SAP EP to service both internal and external (Internet) users. The
SAP EP can only authenticate against one directory. We don't (for obvious
reasons) want to put our external users in our internal AD. I think that ADAM
would be a perfect fit for this. The question is how to sync
passwords.
I could use the
MS solution and use the free* MIIS which looks like it will do exactly what I
want, but with a considerable bit of added complexity. Also, we use Psynch to
let internal (INTRANET domain) users manage their passwords, and I'm afraid the
password hook it requires on the domain controllers will not play nice with the
MIIS password hook.
I can easily code
up my own code to do the simple user object syncing required, but passwords
would be tricky. Fortunately, I don't need to do the password sync.
The external users (EXTRANET domain) use an internally developed web
based app to manage passwords,
so I can hook into it easily enough to change the passwords in ADAM. As for
our internal users (INTRANET domain), I'm pretty sure Psynch can change
passwords in ADAM for me, or at least provide hooks for me to code it up
myself.
After reading
about the proxy user object, I thought it seemed a natural fit for our internal
users. That would eliminate on half of the password syncing issues. However, I'm
rather concerned about the warning on not using them.
BTW, I've been
playing with trying to programmatically create proxy user objects without much
luck. You have to supply the target SID when creating the object. I've tried
using the binary SID as returned from a Get("objectSID") call to the INTRANET
domain user object, and I've tried the "human readable" version "S-..." (which
is what LDP expects when creating a proxy user). Neither seem to work. Anyone
know the proper incantation for this bit of magic?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al
Mulnick
Sent: Sunday, July 31, 2005 11:33 AM To: ActiveDir@mail.activedir.org; ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: MIIS, ADAM, & AD I'll be a lot more interested
in MIIS when "free" doesn't mean I have to "buy" SQL licenses to run it. I can
understand the server license for Windows, but it should run on any version of
the latest Windows server (enterprise, standard, etc) or a desktop OS. Not sure
why that is not possible, unless maybe there's a wait for the new SQL 2005
products.
Anyway, I'm with Joe on this. I think
the simpler you can keep it the better. Writing it in-house with a series of
scripts may be enough to do what you want and it's not too terribly
difficult.
As for proxy objects, if I recall correctly
you typically don't want to use them because of the security issues and
because it's really designed for legacy apps. If you can use AD, use
AD. If you have to use simple bind, then proxy objects may fit the
requirement as long as you remember to use some sort of transport
security.
You may have a problem with multiple
forests as well. Haven't tried that, but since it's a proxy bind, I
imagine it may get a little confused. I'd be interested to hear if that's
not the case though.
Al From: [EMAIL PROTECTED] on behalf of Robert Bobel Sent: Sun 7/31/2005 10:56 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] OT: MIIS, ADAM, & AD Nice side benefit is that the license to use MIIS with the Feature Integration pack to sync AD to ADAM is free.
Bob
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe
Where is this going to be located? Extranet or Intranet?
If you are going to be doing some very simple syncing, I would look at writing something myself or maybe implementing one of the lighter syncing tools like SimpleSync or HP's LDSU. If you need to do a lot of transforms or complex translations or connect to lots of different data sources such as SAP, etc, MIIS might be where you want to go. If you spin up MIIS, it is possible you may need to have a body sitting there maintaining and troubleshooting it due to its complexity plus it is really in flux right now in my opinion in terms of how many things they are looking to change and/or add to it.
How is the data in the directory to be used? Is it going to be an auth point for apps or ???
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Ken
Cornetet We have an upcoming project which will require an LDAP directory containing both our internal users, and our extranet users. Currently, our internal users are in one AD domain, the extranet users are in another. The domains are in separate forests, and there are no trusts.
My plan is to use ADAM for the central LDAP directory. However, I'm on the horns of an enema, um, I mean dilemma on how to sync ADAM to the two domains. A first glance would suggest MIIS. However, MIIS looks pretty complicated, and difficult to configure.
I'm considering writing my own sync code since the task at hand is relatively straight-forward. Passwords will be a bit of a problem, but not unworkable. We use Psynch to maintain our internal passwords, so I can have it change the ADAM passwords at the same time it changes the internal AD passwords. The extranet users change their password via an existing web app, so having it change the ADAM passwords won't be an issue.
Reading about ADAM "proxy users" leads me to believe they'd be a perfect fit as the object type to use for our internal users (authentication is relayed to AD thus negating the need to sync passwords). However, the ADAM tech ref says proxy users should only be used as a last resort, and to refer to the next section as to why. Unfortunately, the next section doesn't explain why not to use them. Anybody know why proxy user objects are evil?
Are there any good "MIIS for dummies" type documentation around? Any good ADAM and/or MIIS mailing lists? |
- RE: [ActiveDir] OT: MIIS, ADAM, & AD Ken Cornetet
- RE: [ActiveDir] OT: MIIS, ADAM, & AD Fugleberg, David A
- RE: [ActiveDir] OT: MIIS, ADAM, & AD Al Mulnick
