|
What
still confuses me is how IIFP is more complex than what you'd have to write
yourself. I can understand if PSynch is not compatible but otherwise it
seems like it's as complex as it needs to be. Therefore, you'd end up
writing the same thing (pretty much). If that's the case, I'm not sure I'd spend
the time writing the code. I prefer to write the code, but not sure it's
justified in this case.
Just
throwing that out there.
Const SE_SACL_PROTECTED = &H2000 Const ADS_SECURITY_INFO_OWNER = &H1 Const ADS_SECURITY_INFO_GROUP = &H2 Const ADS_OPTION_SECURITY_MASK =&H3 Const ADS_SECURITY_INFO_DACL = &H4 Const ADS_SECURITY_INFO_SACL = &H8 Const ADS_ACETYPE_SYSTEM_AUDIT = &H2 Const ADS_ACETYPE_SYSTEM_AUDIT_OBJECT = &H7 Const ADS_RIGHT_DELETE = &H10000 Const ADS_ACEFLAG_FAILED_ACCESS = &h80 Const ADS_ACEFLAG_SUCCESS_ACCESS = &H40 Const ADS_ACEFLAG_NO_PROPAGATE_INHERIT_ACE = &H4 ADS_SID_HEXSTRING = ADS_SID_RAW + 1 ADS_SID_SAM = ADS_SID_HEXSTRING + 1 ADS_SID_UPN = ADS_SID_SAM + 1 ADS_SID_SDDL = ADS_SID_UPN + 1 ADS_SID_WINNT_PATH = ADS_SID_SDDL + 1 ADS_SID_ACTIVE_DIRECTORY_PATH = ADS_SID_WINNT_PATH + 1 ADS_SID_SID_BINDING = ADS_SID_ACTIVE_DIRECTORY_PATH + 1 '------------------------- Main Script ---------------------------- dim oPrv set oPrv = GetObject("LDAP:")
'This section identifies the object that you want to audit.
set oObj = GetObject("LDAP://kwchild:50000/CN=Testuser6,cn=Testcontainer,cn=testrep,dc=com")
'This section identifies the group or user you want to audit when they access the 'object.
set oGRP = oPrv.OpenDsObject("LDAP://kwchild:50000/CN=Users,cn=Roles,cn=testrep,dc=com", "domain\user", "secret", 1)
oObj.SetOption ADS_OPTION_SECURITY_MASK, ADS_SECURITY_INFO_SACL
dim oSD set oSD = oOBJ.Get("ntSecurityDescriptor") dim oSACL set oSACL = oSD.SystemACL
' This section creates a SACL if a SACL does not already exist.
if (oSACL is nothing )then 'make a new sacl set oSACL = createobject("Accesscontrollist") oSACL.aclrevision = 4 end if
' This section converts the dis to SDDL format.
bSID = oObj.Get("objectSID") set oSID = CreateObject("ADsSID") oSID.SetAs ADS_SID_RAW, oGRP.Get("objectSID") strSDDL = oSID.GetAs(ADS_SID_SDDL)
'WScript.Echo "Group SDDL SID: " & strSDDL
dim oAuditACE
'This section constructs the new ACE.
set oAuditAce = CreateObject("AccessControlEntry")
oAuditAce.Trustee = strSDDL
' system audit ace oAuditAce.AceType = 2
' delete audit oAuditAce.AccessMask = ADS_RIGHT_DELETE
'Const ADS_ACEFLAG_FAILED_ACCESS = &h80 'Const ADS_ACEFLAG_SUCCESS_ACCESS = &H40
oAuditAce.AceFlags = ADS_ACEFLAG_SUCCESS_ACCESS or ADS_ACEFLAG_FAILED_ACCESS '&hC0
oAuditAce.Flags = 0
oSACL.AddAce oAuditAce
oSD.SystemACL = oSACL
oOBj.Put "NtSecurityDescriptor", oSD oObj.SetInfo
wscript.echo "done"
I've
been thinking about the exact same scenario, for the same reasons...Some
months ago, there was a presentation at the local Microsoft office by a large
local company that's using the proxy object method. They put their
extranet users directly in ADAM, and built some internal code to create proxy
objects in ADAM for their internal users. The portal authenticates using
simple LDAP binds (over SSL) to ADAM. I have talked to the presenter a
couple of times since then, and they seem to be happy with the functionality
and performance. I really don't know what the 'security concerns' are
regarding using proxy objects, other than the normal concerns around using
simple binds, but SSL helps mitigate those. On the back end (the proxy
authentication to AD), normal AD authentication is used IIRC. Seems like
a pretty good approach, assuming you can automagically create/delete proxy
objects as users come and go from the intranet directory.
If
you did go down the path of synchronized user objects in ADAM, why not use
P-Synch for both the INTRANET and EXTRANET domains ? In other words, an
extranet user would have an object in ADAM and EXTRANET, and would have those
two targets configured in P-Synch. Any password change on the
extranet would get hooked by the P-Synch DLL on the extranet DCs and
transparently synched to ADAM, so you shouldn't need to write any
hooks to your home-grown password change mechanism...
Yet
another solution that's been suggested to me is to use a 'virtual directory'
product to virtualize the internal and external directories into a single
image that's used by the portal. I have no experience with these
products, but perhaps someone else could comment.
Short summary is that we don't have a solution nailed down yet either,
but it sounds like a common problem/scenario. In fact, I almost could
have written your original post word for word....
Dave
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:
[email protected]
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.
http://www.microsoft.com/downloads/details.aspx?familyid=D9143610-C04D-41C4-B7EA-6F56819769D5&displaylang=en
Bob
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Saturday, July 30, 2005 7:59
PM
To:
[email protected]
Subject: RE: [ActiveDir] OT: MIIS,
ADAM, & AD
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
Sent: Friday, July 29, 2005 10:03
AM
To:
[email protected]
Subject: [ActiveDir] OT: MIIS, ADAM,
& AD
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?
|
