It may or may not be related, but I had a similar problem when
assigning user accounts and then trying to add NTFS permissions on a
domain controller other than the Primary. I found that you have to
synchronize the domain controllers before you try to add permissions to
other servers. There is a function in Win32::Lanman which forces domain
synchronization, and it's a pretty fast process. When I wrote my
script, I allowed 45 seconds for the sync to take place, and found that
the entry was in the system log in about ten seconds.
Hope this helps, and if it isn't relevant, I apologize.
--Chuck
--- John Pollock <[EMAIL PROTECTED]> wrote:
> I've been seeing a repeatable problem using a variety of Perl
> modules, and
> thought i'd float the question here.
>
> I have two domains with a one-way trust between them. Both domains
> are
> "master domains" in the sense that they have user accounts in them.
> I
> wrote a Perl script for creating users and i use the script for
> creating
> users in both domains. The script works fine for creating user
> accounts
> and modifying their attributes (using the Win32API module). However,
> i'm
> running into trouble using Win32::FileSecurity for assigning NTFS
> permissions to folders, and it's the same trouble i ran into when
> trying
> to use cacls for the same purpose.
>
> Here are the conditions of the problem:
> 1) i run my script from a machine in the trusted domain (CURL)
> 2) I tell it to modify permissions for a folder in the trusting
> domain
> (CURLCON)
> 3) I tell it to add rights to that folder for a user in the trusting
> domain (CURLCON)
>
> If i do this, the script returns "null\username" and then an error
> after
> it. The script has no problem if i assign a CURL account to the
> folder,
> only if i assign a CURLCON account. I believe it has something to do
> with
> the fact that my machine running the script belongs to a domain that
> doesn't trust the other domain, so it has trouble handling accounts
> from
> that domain. However:
>
> 1) my script was able to create an account in the CURLCON domain and
> modify that account.
> 2) If i use Windows Explorer from a machine in the CURL domain, i'm
> able
> to assign a CURLCON account to a folder on a CURLCON machine.
>
> Therefore, the limitation appears to be within the FileSecurity
> module.
> My question is this: is it possible for me to tell the FileSecurity
> module
> which domain the account to assign permissions to belongs to? Or
> does it
> automatically assume that it's manipulating an account in the same
> domain
> as where the script is running from? I tried passing
> "CURLCON\\username"
> into the hash i built, but it wouldn't accept it...
>
> Thanks in advance!
> John
__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/
_______________________________________________
Perl-Win32-Admin mailing list
[EMAIL PROTECTED]
http://listserv.ActiveState.com/mailman/listinfo/perl-win32-admin
