[wpkg-users] WPKG selectivity based on Windows AD security groups membership
Rainer Meier
r.meier at wpkg.org
Sat Feb 27 19:35:45 CET 2010
Hi Vasaris,
On 27.02.2010 18:51, Vasaris wrote:
> Does that means, that I have to change server-side WPKG files and folders tree, and then find & add this patch to try it out?
Actually you would just have to replace wpkg.js with the patched one from
Bugzilla. If I am not wrong it might be the one posted here:
<http://bugzilla.wpkg.org/show_bug.cgi?id=118>
Caution: I did not verify or ever use this version.
> I very well understand this issue. If you go open-source and try to avoid M$ as much as possible, using AD is an overkill. And it is better to have reduced functionality, then a mess with non-working code.
It's not only to avoid Microsoft. It's mainly about testing possibilities and
also about language capabilities. WPKG uses JScript which is no longer actively
supported by Microsoft and the language capabilities are quite limited. At some
points we are entering some undocumented and even unstable API areas which might
lead to problems.
As soon as we would officially announce AD group support people will start using
it and expect it to work. In worst case we will get requests to implement things
which cannot be done using JScript. On the other side testers and developers
would have to verify each enhancement/change for AD code parts as well. Not
everybody might have licenses of the respective server software to build an AD.
On the other side if there is no AD support this will just enforce admins to
duplicate some information which is supposed to be quite static. So the
drawbacks seem not to be a no-go criteria to me.
However with an architectural change I would like to achieve certain decoupling
between XML-based configuration and AD-based configuration so impacts should be
smaller.
>> So for the moment we stick to XML package/host/profile definition.
>
> This is not a big deal. It just means, that in my case I will have to maintain two membership sets.
>
> Perhaps there is workaround by using some tool to dump security membership content to the profile-host XML files. Therefore, such tool/script might run periodically to upate WPKG XML files to reflect current AD security group memberships.
There are some script examples on wpkg.org already:
<http://wpkg.org/WPKG_with_Active_Directory>
Either this or some modification of it would allow you to generate hosts and
profiles.xml from active directory. Running it frequently using the task
scheduler should be a way to go as well. Even without affecting WPKG and having
to introduce code to wpkg.js which might break or at least create unnecessary
complexity.
Another reason for me is that WPKG currently only uses SMB/CIFS shares and reads
files from it. Remember that wpkg.js is running on the client within WSH. So
accessing AD structures from the client is a new communication channel which
introduces potential problems (like firewalling, timeout, privileges etc.). WPKG
is run from the local system account which might (not must, but might, will have
to verify) have impact on the privileges required to access AD structures.
Running an export/synchronization script on the server which fetches data from
AD and writes it to XML seems to be a much more clever way to go.
Another negative side effect of integrating AD connectivity in wpkg.js is just
the code overhead. Currently wpkg.js is already ~200kB in Size which has to be
fetched by WSH and run within the interpreter. Adding AD/LDAP support might
easily add another 40kB of code.
Sorry for the longish explanation, I was just in the mood to summarize the topic
again since it pops up from time to time. So in the future I can refer to this
message where my main concerns are already written down.
br,
Rainer
More information about the wpkg-users
mailing list