samba - Sep 2017 - samba 4 ad member - idmap = ad for machine accounts

Hello,
Thanks for quick reply.

File server config looks exactly like this, except more shares, all with 
same simple config. I know that "use defualt domain" isn't
necessery,
but it's not the issue for me right now.

[global]
        netbios name = VS-FILES
        security = ADS
        workgroup = MYDOMAIN
        realm = MYDOMAIN.COM

        log file = /var/log/samba/%m.log
        log level = 1

        idmap config *:backend = tdb
        idmap config *:range = 100-2000


        idmap config MYDOMAIN:backend = ad
        idmap config MYDOMAIN:schema_mode = rfc2307
        idmap config MYDOMAIN:range = 4000-99999

         winbind enum users = yes
         winbind enum groups = yes
         winbind nested groups = yes
         winbind expand groups = 5
         winbind use default domain = yes
         winbind nss info = rfc2307
         vfs objects = acl_xattr
         map acl inherit = yes
         store dos attributes = yes

[SOME_SHARE]
         path = /home/shares/SOME_SHARE/
         read only = no



Some uses I have for machine accounts:
1) I have v. important windows application that is running as windows 
service as "SYSTEM" account. It writes a lot of image-type files. 
Because it's running as SYSTEM, machine account has to have
"read/write"
to the share.
2)'m using some machine autostart scripts, for various tasks, which work 
again as SYSTEM, so if they have to get anything from network share, 
they need to have read/write permission. What I'm doing is, for example, 
as autostart run a batch script, that would check 
\\fileserver\public\test-file.txt if %COMPTURNAME% exists in this file. 
if not - run some robocopy script, then >> %COMPUTERNAME% to the end of 
the file.
or even something simple like this:
"if exist \\server\share\%computername%.txt (exit)
else robocopy some-files
echo . > \\server\share\%computername%.txt
exit"
3) Some windows applications that I use also run as SYSTEM account and 
they have built-in backup utilities, and if I want to backup straight to 
network share - again - machine account needs direct write access to share.

I do know that machine accounts are "normal" accounts, and I tried 
simply adding them to windows ACL, but it just tidn't work. I had to go 
with "idmap = rid", and it did just fine, so the issue must be iwth 
idmap backend - ad not supplying valid uid for winbind, right?

W dniu 2017-09-17 o 19:50, Rowland Penny via samba
pisze:
> On Sun, 17 Sep 2017 18:14:45 +0200
> Kacper Wirski via samba <samba at lists.samba.org> wrote:
>
>> Hello,
>>
>> I have samba 4.5.10 file server as AD member (AD is also samba
>> 4.5.10).
>>
>> I'm using unix extension for windows rsat to set UIDs for all users
>> and on samba AD member i'd prefer to use idmap = ad to have
>> consistent file permissions across multiple file servers.
>>
>> My issue is with machine accounts. RSAT extension doesn't allow for
>> easy "uid" setting for machine accounts. I've been trying
with ldap
>> editor to set  UID, primary group ID etc. ,but without success.
>>
>> Why do I need this?
> Short answer, you don't for machine accounts
>
>> When task on a PC is run as SYSTEM and should access network share,
>> windows will try to use it's machine account instead. I'm using
some
>> backup tasks and other scripts that are supposed to store output in
>> network shares, for this to work I simply want to give read-write
>> permissions to machine accounts, and wit idmap = AD those accounts
>> have no UID.
> Ah, I think you may be mistaking Kerberos machine accounts for machine
> accounts. Let me guess, you come from a Samba 3 way of doing things ;-)
>
>>
>>    With idmap = rid everything works obviously fine, but I'm not
sure
>> how consistent permissions will be across servers.
> You can get consistent IDs on Unix domain members with the 'rid'
> backend, but you will have different IDs on a Samba DC
>
>> What I'm planning to do is setting idmap uid range something like
>> 5000 - 99999, with 10,000 + for users (default setting), and use
>> 5000+ for machines. This way I have large enough margin, so it
won't
>> overlap with users, and it will not interfere with rsat
>> auto-increnemt by one.
> You do not need uidNumbers for machines and I cannot recommend your
> suggested ranges. You should be aware, as far as AD is concerned, a
> computer is also a user.
>
>> Samba unix settings are minimal, all permissions are set using
>> windows GUI.
> Or to put it another way, you are using Windows ACLs
>
>> My question comes down to this:
>>
>> - which LDAP attributes of an AD joined windows PC should be edited,
>> so it will have access to samba 4 share with it's machine account,
>> when using idmap = AD in the same way, that domain users do, when
>> using NIS extension for RSAT?
> I think this may be the wrong question, I think you may be better
> asking how do I make my scripts work with Samba AD
>
> Can I suggest you read this wikipage:
>
> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>
> I have updated it today, to try and make the range setting etc a bit
> more understandable.
>
> It will definitely help if you post the smb.conf you are using on your
> Unix domain member (what you call a fileserver)
>
> As you cannot attach files to posts to this list, can I suggest you
> send me (offlist) one of the scripts you are having problems with and I
> will try to advise just were you may be going wrong.
>
> Rowland
>
>

On Sun, 17 Sep 2017 21:37:37 +0200
Kacper Wirski via samba <samba at lists.samba.org> wrote:
> Hello,
> Thanks for quick reply.
> 
> File server config looks exactly like this, except more shares, all
> with same simple config. I know that "use defualt domain"
isn't
> necessery, but it's not the issue for me right now.
> 
> [global]
>         netbios name = VS-FILES
>         security = ADS
>         workgroup = MYDOMAIN
>         realm = MYDOMAIN.COM
> 
>         log file = /var/log/samba/%m.log
>         log level = 1
> 
>         idmap config *:backend = tdb
>         idmap config *:range = 100-2000
> 
> 
>         idmap config MYDOMAIN:backend = ad
>         idmap config MYDOMAIN:schema_mode = rfc2307
>         idmap config MYDOMAIN:range = 4000-99999
Have you read the Samba wikipage I pointed you to ? 

Your '*' range tramples all over the local system users and ends 1000
above where the local Unix users & groups are supposed to be stored.
> 
>          winbind enum users = yes
>          winbind enum groups = yes
You should remove the above two lines once you have everything working,
you should only use them for testing purposes.
>          winbind nested groups = yes
>          winbind expand groups = 5
>          winbind use default domain = yes
>          winbind nss info = rfc2307
>          vfs objects = acl_xattr
>          map acl inherit = yes
>          store dos attributes = yes
> 
> [SOME_SHARE]
>          path = /home/shares/SOME_SHARE/
>          read only = no
> 
> 
> 
> Some uses I have for machine accounts:
> 1) I have v. important windows application that is running as windows 
> service as "SYSTEM" account. It writes a lot of image-type files.
> Because it's running as SYSTEM, machine account has to have
> "read/write" to the share.
'SYSTEM' is a Windows group and is meaningless to Unix, it should be
mapped to a Unix ID only on a Samba AD DC and there it is an
'xidNumber' not a 'uidNumber or 'gidNumber'. Running
'wbinfo -S
S-1-5-18' (the SID for 'SYSTEM' is S-1-5-8-18) on a UNIX domain
member,
returns:
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-18 to uid

However "wbinfo -Y  S-1-5-18" returns:
2005 (note your ID may be different)

As I said, you could use the kerberos machine account instead, but are
these scripts being run on the fileserver, Samba DC or windows
machines ? if the later, then you shouldn't need a Unix IDs.
> 2)'m using some machine autostart scripts, for various tasks, which
> work again as SYSTEM, so if they have to get anything from network
> share, they need to have read/write permission. What I'm doing is,
> for example, as autostart run a batch script, that would check 
> \\fileserver\public\test-file.txt if %COMPTURNAME% exists in this
> file. if not - run some robocopy script, then >> %COMPUTERNAME% to
> the end of the file.
> or even something simple like this:
> "if exist \\server\share\%computername%.txt (exit)
> else robocopy some-files
> echo . > \\server\share\%computername%.txt
> exit"
That looks like a Windows script (not that I am an expert on Windows
script languages) so I presume that it is run a Windows machine and
'SYSTEM' should be available on it via its name or SID.
> 3) Some windows applications that I use also run as SYSTEM account
> and they have built-in backup utilities, and if I want to backup
> straight to network share - again - machine account needs direct
> write access to share.
Hmm, I think I am beginning to understand your problem, you are
confusing 'SYSTEM' with the computers account in AD.

'SYSTEM' does not exist in AD, so you cannot give it a uidNumber or
gidNumber attribute.

I think you need to find another way to do what you are doing now.
> 
> I do know that machine accounts are "normal" accounts, and I
tried
> simply adding them to windows ACL, but it just tidn't work. I had to
> go with "idmap = rid", and it did just fine, so the issue must be
> iwth idmap backend - ad not supplying valid uid for winbind, right?
> 
You should be able to add a uidNumber to a computer, but to make it
work as a user on Unix, you will have to give the Domain Computers
group a gidNumber.

Rowland

Hello,

I think I'm not explaining the issue correctly and I'm being
misunderstood.

I'll give an example:

windows 7 machine PC1$ is running AD GPO startup script that forces it 
to read some files from network share hosted on the centos server with 
samba 4.

The script will be run as windows SYSTEM user (that's the default 
behaviour of autostart scripts).

But since SYSTEM is a local windows user it's unable to authenticate to 
the network share, Windows knows this, so to access network share will 
try to use credentials of the PC1$ machine account instead (the only one 
it really knows), and it fails. It fails becuase samba is unable to map 
PC$ to any of the accounts from smb.conf, since it PC1$ will have NO UID 
no PRIMARY GROUP etc.. It won't have those values, because idmap = ad 
forces samba member to read those values from AD, and machine accounts 
don't have those set in any way, that I was able to find.

At first I thought that setting windows ACL should "just work" but it 
didn't, only switching idmap to rid helped, as I was unable to find the 
correct attributes to set in the AD for machineaccounts$ - that's why I 
asked my question :)

I've tried creating a clone of this server with only difference in 
smb.conf being idmap = rid.  And then everything works flawlessly, with 
all machine accounts$ being able to do, what I need to them to do. This 
is obvious to me, that all I'm lacking is some settings in machine 
accounts (domain joined windows machines) in the ldap attributes, those 
attributes that are set with windows RSAT - unix attributes: nisdomain, 
user id, primary group

So my goal is to enable "MYDOMAIN\Domain Computers" or any of the 
machineaccounts$ to be able to access read/write files from samba 4 
domain server.

As to my smb.conf.

The values for ranges are working for me, because no user and or groups 
in passwd or groups are "overlapping".

The server is a centos minimal install with just samba 4 running and has 
no "local" users except for some default system (with uids <100)
and
will never ever use any. It's a virtual machine used ONLY as a file 
server without any users except for root. It was used as file server for 
some time without issues - except for the "domain computers" group 
and/or individual machine accounts (computer accounts that is).


The script is windows batch script. When script is used as GPO for 
"autostart" it's ran as local SYSTEM, soe when SYSTEM looks up if
file
exists in network share it's trying to use it's
"machineaccount$" to
access and that's when it fails with idmap = ad, but succeeds with idmap 
= rid. And that's because for idmap = ad I have to set proper UID and 
nisdomain values through RSAT (or other means) to users. ANd while there 
is good tool for "normal" accounts, it's unavaiable for computer
accounts.

Yes, computer accounts are almost the same as user accounts, but from 
windows RSAT point of view, the options are not the samme. WHat I'm 
simply asking is this:

- which of the machineaccount$ AD attributes should be "manually" 
edited, to achieve same effect, as setting nisdomain and UID through 
windows RSAT unix extension? I've been looking at the ldap editor, I've 
managed to get the attributes which should be enough (I think primary 
group, uid and gid), I managed to get proper output from winbind: it was 
able to read the user id and group id of one of the machine accounts, 
but still didn't allow it access to the share.


I hope I'm making myself clear enough.


W dniu 2017-09-17 o 22:46, Rowland Penny via samba
pisze:
> On Sun, 17 Sep 2017 21:37:37 +0200
> Kacper Wirski via samba <samba at lists.samba.org> wrote:
>
>> Hello,
>> Thanks for quick reply.
>>
>> File server config looks exactly like this, except more shares, all
>> with same simple config. I know that "use defualt domain"
isn't
>> necessery, but it's not the issue for me right now.
>>
>> [global]
>>          netbios name = VS-FILES
>>          security = ADS
>>          workgroup = MYDOMAIN
>>          realm = MYDOMAIN.COM
>>
>>          log file = /var/log/samba/%m.log
>>          log level = 1
>>
>>          idmap config *:backend = tdb
>>          idmap config *:range = 100-2000
>>
>>
>>          idmap config MYDOMAIN:backend = ad
>>          idmap config MYDOMAIN:schema_mode = rfc2307
>>          idmap config MYDOMAIN:range = 4000-99999
> Have you read the Samba wikipage I pointed you to ?
>
> Your '*' range tramples all over the local system users and ends
1000
> above where the local Unix users & groups are supposed to be stored.
>
>>           winbind enum users = yes
>>           winbind enum groups = yes
> You should remove the above two lines once you have everything working,
> you should only use them for testing purposes.
>
>>           winbind nested groups = yes
>>           winbind expand groups = 5
>>           winbind use default domain = yes
>>           winbind nss info = rfc2307
>>           vfs objects = acl_xattr
>>           map acl inherit = yes
>>           store dos attributes = yes
>>
>> [SOME_SHARE]
>>           path = /home/shares/SOME_SHARE/
>>           read only = no
>>
>>
>>
>> Some uses I have for machine accounts:
>> 1) I have v. important windows application that is running as windows
>> service as "SYSTEM" account. It writes a lot of image-type
files.
>> Because it's running as SYSTEM, machine account has to have
>> "read/write" to the share.
> 'SYSTEM' is a Windows group and is meaningless to Unix, it should
be
> mapped to a Unix ID only on a Samba AD DC and there it is an
> 'xidNumber' not a 'uidNumber or 'gidNumber'. Running
'wbinfo -S
> S-1-5-18' (the SID for 'SYSTEM' is S-1-5-8-18) on a UNIX domain
member,
> returns:
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-18 to uid
>
> However "wbinfo -Y  S-1-5-18" returns:
> 2005 (note your ID may be different)
>
> As I said, you could use the kerberos machine account instead, but are
> these scripts being run on the fileserver, Samba DC or windows
> machines ? if the later, then you shouldn't need a Unix IDs.
>
>> 2)'m using some machine autostart scripts, for various tasks, which
>> work again as SYSTEM, so if they have to get anything from network
>> share, they need to have read/write permission. What I'm doing is,
>> for example, as autostart run a batch script, that would check
>> \\fileserver\public\test-file.txt if %COMPTURNAME% exists in this
>> file. if not - run some robocopy script, then >> %COMPUTERNAME%
to
>> the end of the file.
>> or even something simple like this:
>> "if exist \\server\share\%computername%.txt (exit)
>> else robocopy some-files
>> echo . > \\server\share\%computername%.txt
>> exit"
> That looks like a Windows script (not that I am an expert on Windows
> script languages) so I presume that it is run a Windows machine and
> 'SYSTEM' should be available on it via its name or SID.
>
>> 3) Some windows applications that I use also run as SYSTEM account
>> and they have built-in backup utilities, and if I want to backup
>> straight to network share - again - machine account needs direct
>> write access to share.
> Hmm, I think I am beginning to understand your problem, you are
> confusing 'SYSTEM' with the computers account in AD.
>
> 'SYSTEM' does not exist in AD, so you cannot give it a uidNumber or
> gidNumber attribute.
>
> I think you need to find another way to do what you are doing now.
>
>> I do know that machine accounts are "normal" accounts, and I
tried
>> simply adding them to windows ACL, but it just tidn't work. I had
to
>> go with "idmap = rid", and it did just fine, so the issue
must be
>> iwth idmap backend - ad not supplying valid uid for winbind, right?
>>
> You should be able to add a uidNumber to a computer, but to make it
> work as a user on Unix, you will have to give the Domain Computers
> group a gidNumber.
>
> Rowland
>

Hi Rowland,
>> File server config looks exactly like this, except more shares, all
>> with same simple config. I know that "use defualt domain"
isn't
>> necessery, but it's not the issue for me right now.
...

> 'SYSTEM' is a Windows group and is meaningless to Unix, it should
be
> mapped to a Unix ID only on a Samba AD DC and there it is an
> 'xidNumber' not a 'uidNumber or 'gidNumber'. Running
'wbinfo -S
> S-1-5-18' (the SID for 'SYSTEM' is S-1-5-8-18) on a UNIX domain
member,
> returns:
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-18 to uid
>
> However "wbinfo -Y  S-1-5-18" returns:
> 2005 (note your ID may be different)
>
> As I said, you could use the kerberos machine account instead, but are
> these scripts being run on the fileserver, Samba DC or windows
> machines ? if the later, then you shouldn't need a Unix IDs.
>
>> 2)'m using some machine autostart scripts, for various tasks, which
>> work again as SYSTEM, so if they have to get anything from network
>> share, they need to have read/write permission. What I'm doing is,
>> for example, as autostart run a batch script, that would check
>> \\fileserver\public\test-file.txt if %COMPTURNAME% exists in this
>> file. if not - run some robocopy script, then >> %COMPUTERNAME%
to
>> the end of the file.
>> or even something simple like this:
>> "if exist \\server\share\%computername%.txt (exit)
>> else robocopy some-files
>> echo . > \\server\share\%computername%.txt
>> exit"
>
> That looks like a Windows script (not that I am an expert on Windows
> script languages) so I presume that it is run a Windows machine and
> 'SYSTEM' should be available on it via its name or SID.
>
>> 3) Some windows applications that I use also run as SYSTEM account
>> and they have built-in backup utilities, and if I want to backup
>> straight to network share - again - machine account needs direct
>> write access to share.
>
> Hmm, I think I am beginning to understand your problem, you are
> confusing 'SYSTEM' with the computers account in AD.
>
> 'SYSTEM' does not exist in AD, so you cannot give it a uidNumber or
> gidNumber attribute.
>
> I think you need to find another way to do what you are doing now.
Kacper way of doing things is completly correct (at least from 
authentication point of view). SYSTEM account on Windows uses the 
machine account for authentication. So for example, using psexec [1], 
you can try (on an elevated command prompt):

  psexec -s -i cmd.exe

Check that you are local system

  whoami

then you connect to a share (sysvol is a good choice here since "domain 
computers" has access)

  net use F: \\domain.lan\sysvol

Then on your DC you can check which account has been used for the connexion:

  smbstatus

You'll see that SYSTEM account uses the Kerberos machine account for 
authentication.

Cheers,

Denis

[1] https://docs.microsoft.com/en-us/sysinternals/downloads/psexec
>
>>
>> I do know that machine accounts are "normal" accounts, and I
tried
>> simply adding them to windows ACL, but it just tidn't work. I had
to
>> go with "idmap = rid", and it did just fine, so the issue
must be
>> iwth idmap backend - ad not supplying valid uid for winbind, right?
>>
>
> You should be able to add a uidNumber to a computer, but to make it
> work as a user on Unix, you will have to give the Domain Computers
> group a gidNumber.
>
> Rowland
>
-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr

Hi Kacper,
> 1) I have v. important windows application that is running as windows
> service as "SYSTEM" account. It writes a lot of image-type files.
> Because it's running as SYSTEM, machine account has to have
"read/write"
> to the share.
Ok. You might take a look if you can lower the account rights from 
SYSTEM to "Network Service" account. It still has access to the
Kerberos
machine account for network connection, but runs with lower privileges.
> 2)'m using some machine autostart scripts, for various tasks, which
work
> again as SYSTEM, so if they have to get anything from network share,
> they need to have read/write permission. What I'm doing is, for
example,
> as autostart run a batch script, that would check
> \\fileserver\public\test-file.txt if %COMPTURNAME% exists in this file.
> if not - run some robocopy script, then >> %COMPUTERNAME% to the end
of
> the file.
> or even something simple like this:
> "if exist \\server\share\%computername%.txt (exit)
> else robocopy some-files
> echo . > \\server\share\%computername%.txt
> exit"
I try to avoid using this kind of remote connection in scripts if 
possible because there are so many things that can go wrong with network 
on a workstation... I'd rather create a software package (you might 
check WAPT at wapt.fr for that) so that every needed pieces are on the 
computer when it has to run.
> 3) Some windows applications that I use also run as SYSTEM account and
> they have built-in backup utilities, and if I want to backup straight to
> network share - again - machine account needs direct write access to share.
If possible, you might try to have the backups done the other way 
around. Indeed, if the windows workstation get a ransomware, it will 
have the credentials to also cryptolock the backup share (even thought I 
guess malware writers currently don't bother to use machine Kerberos 
account).
> I do know that machine accounts are "normal" accounts, and I
tried
> simply adding them to windows ACL, but it just tidn't work. I had to go
> with "idmap = rid", and it did just fine, so the issue must be
iwth
> idmap backend - ad not supplying valid uid for winbind, right?
RID is just fine as an IDMAP. Actually, it is the best solution in the 
large majority of cases. If you use RID, all fileservers will have the 
same mapping. Yeah your DC won't have a consistent mapping, but you 
mostly don't care (and using the plain old TDB mapping on DC will 
prevent you from falling into the "domain admins" gidnumber vs
xidnumber
pitfall).

Cheers,

Denis


> W dniu 2017-09-17 o 19:50, Rowland Penny via samba pisze:
>> On Sun, 17 Sep 2017 18:14:45 +0200
>> Kacper Wirski via samba <samba at lists.samba.org> wrote:
>>
>>> Hello,
>>>
>>> I have samba 4.5.10 file server as AD member (AD is also samba
>>> 4.5.10).
>>>
>>> I'm using unix extension for windows rsat to set UIDs for all
users
>>> and on samba AD member i'd prefer to use idmap = ad to have
>>> consistent file permissions across multiple file servers.
>>>
>>> My issue is with machine accounts. RSAT extension doesn't allow
for
>>> easy "uid" setting for machine accounts. I've been
trying with ldap
>>> editor to set  UID, primary group ID etc. ,but without success.
>>>
>>> Why do I need this?
>> Short answer, you don't for machine accounts
>>
>>> When task on a PC is run as SYSTEM and should access network share,
>>> windows will try to use it's machine account instead. I'm
using some
>>> backup tasks and other scripts that are supposed to store output in
>>> network shares, for this to work I simply want to give read-write
>>> permissions to machine accounts, and wit idmap = AD those accounts
>>> have no UID.
>> Ah, I think you may be mistaking Kerberos machine accounts for machine
>> accounts. Let me guess, you come from a Samba 3 way of doing things ;-)
>>
>>>
>>>    With idmap = rid everything works obviously fine, but I'm
not sure
>>> how consistent permissions will be across servers.
>> You can get consistent IDs on Unix domain members with the
'rid'
>> backend, but you will have different IDs on a Samba DC
>>
>>> What I'm planning to do is setting idmap uid range something
like
>>> 5000 - 99999, with 10,000 + for users (default setting), and use
>>> 5000+ for machines. This way I have large enough margin, so it
won't
>>> overlap with users, and it will not interfere with rsat
>>> auto-increnemt by one.
>> You do not need uidNumbers for machines and I cannot recommend your
>> suggested ranges. You should be aware, as far as AD is concerned, a
>> computer is also a user.
>>
>>> Samba unix settings are minimal, all permissions are set using
>>> windows GUI.
>> Or to put it another way, you are using Windows ACLs
>>
>>> My question comes down to this:
>>>
>>> - which LDAP attributes of an AD joined windows PC should be
edited,
>>> so it will have access to samba 4 share with it's machine
account,
>>> when using idmap = AD in the same way, that domain users do, when
>>> using NIS extension for RSAT?
>> I think this may be the wrong question, I think you may be better
>> asking how do I make my scripts work with Samba AD
>>
>> Can I suggest you read this wikipage:
>>
>> https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member
>>
>> I have updated it today, to try and make the range setting etc a bit
>> more understandable.
>>
>> It will definitely help if you post the smb.conf you are using on your
>> Unix domain member (what you call a fileserver)
>>
>> As you cannot attach files to posts to this list, can I suggest you
>> send me (offlist) one of the scripts you are having problems with and I
>> will try to advise just were you may be going wrong.
>>
>> Rowland
>>
>>
>
>
>
>
-- 
Denis Cardon
Tranquil IT Systems
Les Espaces Jules Verne, bâtiment A
12 avenue Jules Verne
44230 Saint Sébastien sur Loire
tel : +33 (0) 2.40.97.57.55
http://www.tranquil-it-systems.fr