Never mind then. I thought I read that the systems involved were Windows.
Systems other than Windows will only evaluate strings for IDs. In that case
pp1234 really *is* pp1234 as far as the QMgr is concerned.
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Tuesday, October 15, 2013 9:23 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Going on the theory that the SID presented when I am logged on from home is
different than the SID presented when I am logged in at work, even though I
type in the same ID and password into the same physical laptop in both case,
it could make sense that pp12345 is not equal to pp12345 when it comes time
for the QM to do its thing with that ID. HOWEVER..
A. The Queue Manager in this scenario is running on Linux. Does that
eliminate the Windows SID from the conversation?
B. When I use a second channel that has a blank MCAUSER and no CHLAUTH
rule that covers that channel name, I can connect to the QM, whether its
pp12345 logged on at work or pp12345 logged on at home. I can access the
queues my group membership says I can, and I get the 2035s I'm supposed to
when I try to access a queue I'm not supposed to. Why would CHLAUTH be
sensitive to SIDs (if they are in play at all, see point A) but the setmqaut
rules don't care?
When I log on at home I'm logging into my laptop before I establish the VPN,
logging into the 'domain' and not the local laptop name, so cached
credentials are in play. Once my VPN is established I do execute my log on
script again to establish my shared drive mappings, and I assume to log into
my domain again, this time for real. So I'll buy the idea that the SID being
presented over the client connection is different when I'm coming in over
the VPN. But why would setmqaut rules be immune to that (which have
historically been very sensitive to SIDs in my experience) but the CHLAUTH
rules get tripped up by it?
At least this problem is consistent. I've repeated it 3 different
days/nights. Things work just fine on the intranet, but the CHLAUTH rule for
User mapping fails to fire when dealing with a connection over a VPN. I'm
building a new QM today on a new server and will test against it. If it
works the same way against a second QM its PMR time.
"So, whip up a SVRCONN with no mapping and put ***@domain-or-host in the
MCAUSER and keep changing the domain-or-host part until you find one that
works. Then put that fully-qualified value in the channel mapping rule for
your target channel. If the client-facing part of the CHLAUTH (the part
that evaluates the client ID on the connection) is resolving strings, this
will work all the time. If not you'd actually have to know all the
***@host and ***@domains that could be sent in."
I can't create a channel with ***@myhost because the MCAUSER field is
restricted to 12 characters on non Windows platforms. This being a Linux
queue manager I would only be able to get in the first few letters of the
host name.
A channel with ***@mydomain in the MCAUSER allows me to connect and I
see the channel running as ***@mydomain. Reminder: Another channel with
a blank MCAUSER and no CHLAUTH rule runs as pp12345 (no domain appended),
whether I connect from home or the office.
I set up a new channel with a Bogus ID in the MCAUSER.
I then set up a CHLAUTH rule looking for ***@mydomain to match against
for this new channel.
DISPLAY CHLAUTH (PETER.TEST.6) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.6) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS(*) CLNTUSER(***@xxx)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-15) ALTTIME(08.48.24)
The rule does not see the client connection as a match. I am in the office
right now. The connection is rejected and the user ID in the Authority Event
message is the bogus ID hard coded in the channel. Sooooooo, this says to
me the CHLAUTH is behaving slightly differently than setmqaut / OAM but we
(or at least I) already suspected that.
Apparently pp12345 or ***@domain are being treated the same by the OAM,
but CHLAUTH is somehow seeing things differently.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Monday, October 14, 2013 11:06 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Hi Peter,
I've been trying for YEARS to get the Infocenter setmqaut examples all
changed to use -g instead of -p. There is only one case where the -p does
what you expect, it's Windows and even there the technique isn't at all
reliable. Here's the scoop.
When you issue setmqaut in Windows, it stores the SID that is resolved. You
give it a string and then Windows name resolution looks first at the local
box, then at all the domains. The OAM saves the string *and* the SID. Now
let's see what happens when you actually try to connect.
If you connect from a Windows device, the SID provided is that of the ID as
resolved by the WMQ client. Sometimes that ID is local, sometimes it is the
domain account. Sometimes it can actually change depending on whether you
are connected to the network *before* or *after* you log into Windows.
Depending on the AD policy you might use a cached ID or a local account.
When the Windows client connects, the QMgr gets the SID and tries to resolve
it. Whether it resolves depends on the interaction of AD policy between the
WMQ host, the laptop and the domain. In some cases a local account is
resolved when the laptop is on the VPN but not when it is connected directly
to the intranet. In some cases the laptop uses a domain account at all
times. Depends on AD policy. The ability of the QMgr to resolve that SID
may change depending on *which* SID is presented and on the connection
itself. Assuming the ID presented by the laptop is static or at least is
good, and the QMgr's host still can't resolve it, another issue is the trust
relationship between the QMgr's host and the domains it knows about. The
SID can live in only one domain and if that domain either drops out of the
search path or refuses to resolve the laptop whilst connected remotely due
to reduced trust of remote devices, again an intermittent failure.
Sometimes though the client connection itself cannot resolve the SID. This
can be because it is a domain account and the domain isn't available or that
policies alter the domain trust when the device is remote. Other times it
is because the ID presented is set through configuration to one that simply
does not exist and can't be resolved by Windows. In all these cases a
string is sent without a SID, just like with non-Windows platforms. When a
string is received by the QMgr it tries to resolve the string using the
local domain search path. First local, then the domains that it knows
about. The *first* domain to resolve the string returns a SID. If that SID
matches what the QMgr resolved the very first time, you are golden.
However, if the ID in question exists in more than one place in the search
path it can resolve to a SID that does *not* match what setmqaut stored.
Depends on the search path and that can change at run time. Again, this can
lead to intermittent failures.
I believe there's a case where the client sends a SID that doesn't match the
string. For example, your JMS app sets the ID to "mqm" but the client sends
the SID of the local user. Not sure if that's true and if so which client
versions it applies to. Also, I do not know whether the CHLAUTH rules
evaluate the SID, the string or both, when evaluating matches on Client ID.
The only way I've ever found to mitigate all of this is to use a
fully-qualified value such as ***@workstationname or ***@domain. This
must be done when issuing the setmqaut command and then subsequently for
every configuration reference to the ID such as MCAUSER or CHLAUTH. I've
stated this in all my conference sessions and tried to influence others to
do so in theirs and even had some luck in getting the Infocenter updated but
it is far from what I would consider to be well documented.
Part of the problem is that none of this is unique to WMQ. *Any* software
that tries to resolve strings to Windows accounts has all of these issues.
In fact, I believe that is part of the reason it's not well documented by
IBM - I think it's generally considered to be a Windows accounts issue and
not strictly a WMQ issue. To a deeply skilled AD person, resolving SIDs or
string values through the domain search path is well known. To WMQ admins
it is a black art. That's pretty much the case with anything adjacent to
WMQ. The mechanics of X.509 certificates, signing, the TLS protocol, etc.
are all well documented elsewhere. The Infocenter docs on these began to
improve when it became clear that WMQ customers weren't finding these
external sources and the difficulty in doing anything with TLS made it a WMQ
problem. Same thing with the WMQ administrative overlap in PowerHA, VCS,
MSCS, etc. All generally considered out of scope for the WMQ Infocenter but
would be extremely helpful for WMQ admins if more of it were there.
So, whip up a SVRCONN with no mapping and put ***@domain-or-host in the
MCAUSER and keep changing the domain-or-host part until you find one that
works. Then put that fully-qualified value in the channel mapping rule for
your target channel. If the client-facing part of the CHLAUTH (the part
that evaluates the client ID on the connection) is resolving strings, this
will work all the time. If not you'd actually have to know all the
***@host and ***@domains that could be sent in.
Filling in for Roger, we *know* that MQAUSX will resolve the string
presented by the client ID and not the SID. If you have an MCAUSER that you
know works but CHLAUTH is still intermittent, MQAUSX can resolve the string
presented and map to a known good MCAUSER (also in ***@domain format) so it
works consistently.
Happy to work with you offline on this. Turns out I have a bit of time this
week. If this doesn't fix it, call me.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Monday, October 14, 2013 20:54 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Here is the test using the IP address of the client server inside the data
center. This test case has the mapping take effect, and the runcheck shows
that. Actual IP address values changed to protect the innocent, although the
# of digits is the same as the actual IP address.
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345')
ADDRESS('10.320.242.284')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123)
Here is the test using the IP address of my laptop coming in over VPN, as
seen from the queue manager. This test case is the one where the mapping
does NOT take effect. Actual IP address values changed to protect the
innocent, although the # of digits is the same as the actual IP address.
DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345')
ADDRESS('10.257.2.50')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123)
According to the runcheck, and common sense, this should also cause the ID
to be flipped from pp12345 to abc123, but for some crazy reason it does not
when I'm client connected to the QM over VPN.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Monday, October 14, 2013 12:58 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
I did not for the MCAUSER because I only have a dummy bogus ID hard coded in
there as a blocker.
I did not for the CHLAUTH rule because none of the examples in the Info
Center mention needing to specify the domain. And when the Authority Events
were thrown the ID listed in the event message did not have a domain, so I
wanted to supply that exact ID into the CHLAUTH rule. I looked in the
CHLAUTH presentation from the 2013 MQ Tech Conference and the only time a
domain is used in the examples is once or twice on the ID to be used for the
effective MCAUSER, never for the incoming ID to be matched against.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Monday, October 14, 2013 11:50 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
So have you tried the ***@domain format when specifying MCAUSER in the
channel or mapping rule?
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Monday, October 14, 2013 9:36 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
"but are the accounts on the home and office PCs local or domain accounts"
The home and office PC are one and the same, my laptop that I bring with me.
I am logged in as a domain ID on my laptop. I use that same domain ID log in
when I get onto a server with just the MQ Client to use as another test
case.
I never see the domain info when I see the ID displayed in an Authority
Event message or in the MCAUSER field of a running channel instance.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Neil Casey
Sent: Monday, October 14, 2013 9:21 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Hi,
this might not be relevant, but are the accounts on the home and office PCs
local or domain accounts, and is the server using domain accounts?
If your home PC has a local account pp12345, and the RDP machine in the
office uses a domain login (also pp12345 but of course actually a different
account) then that might account for the different behaviour.
However, the manual doesn't mention that domain or SID is checked. it just
says the client asserted userid.
Regards,
Neil Casey
mailto:Neil_Casey-8K57OPj+***@public.gmane.org mobile: +61 414 615 334
On 15/10/2013, at 12:02 AM, "Costa, D. (Damian)" <DamianC-3zJjxGF14/***@public.gmane.org>
wrote:
Hi,
Peter we're doing the same sort of stuff but on MQ V 7.1 we are also
dialling into the office network via VPN's and such but there is no
connectivity failures to MQ V7.1 qmgrs with chl auth rules enabled.
Looks to me you'll really have to look under the covers here. So no avoiding
a trace file or two I'm afraid.
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: 14 October 2013 02:53 PM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Interesting. I decided to play around with this some more last night. The
behavior reverted to what I had originally posted - the CHLAUTH rule to map
pp12345 to abc123 was not being invoked even though I was connecting over
the named channel and as that ID.
This morning its working again as expected.
My test cases are identical except for one thing I realized. When I'm
working from home they don't work as expected, when I'm logged in at the
office they work as expected. When I'm working from home I'm coming in over
a VPN tunnel. The MQ Client connection originates from my physical laptop
where I am logged in as pp12345, and the Queue Manager resides on a server
inside our data center.
I originally set up the CHLAUTH rule when I was working from home and never
got the expected mapping to work - my opening post. When I reported it
started working, I was in the office. Last night it stopped working, I was
at home. This morning its working again as I test from the office.
Even though there is no CHLAUTH rule based on IP address I did try the
following when I was working from home. I RDP'ed onto an unrelated server
that had MQ Client installed and repeated the same test. Even though I and
my laptop were at home coming in over the VPN, my test case was executing
directly on the server. The CHLAUTH rule worked. And I tried that same test
this morning in the office, RDP'ing to the other server. It works. So its
not IP based.
It seems the connection over VPN is doing something that causes the CHLAUTH
rule to not fire. Its not IP address related, since I proved coming from
different IPs doesn't matter, and there isn't an IP based CHLAUTH rule
anyway. I thought maybe the ID that was sent by the client was somehow
messed with over the VPN connection, but that's not it because when I tried
to connect over another client channel with a blank MCAUSER and no CHLAUTH
rule the ID shown in the running channel was pp12345. And if I tried to
access a queue I wasn't allowed to the Authority Event showed pp12345.
Very odd. Anyone have any ideas why this is behaving like this?
I'm going to try one more time tonight from home and if the pattern persists
I guess its time to run a trace on the Queue Manager for both test cases
(from the office and from home) and open a PMR.
Peter Potkay
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO
Architecture + Engineering)
Sent: Friday, October 11, 2013 10:00 AM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
Damian,
I suspected that, but when I make a connection over the channel the active
channel shows the ID in use as lowercase.
When I try to access queues I don't have rights to, the Authority Events
show the ID in lowercase as well.
I think everything is using lowercase.
This morning, its working as expected. No changes were made to the channel
or the CHLAUTH rules. The same test cases used yesterday that were not
causing the mapping to kick in are working as expected today. The only thing
done was after I sent the original email I started playing with the RUNCHECK
option of the DISPLAY CHLAUTH command to see what it returned. Its as if the
RUNCHECK gave the QM a kick in the pants to start respecting this USERMAP
CHLAUTH rule. Other CHLAUTH rules (not related to mapping User IDs) were
working fine before this though. New USERMAP rules I have played with this
morning all work right away as expected.
3 : DISPLAY CHLAUTH(PETER.TEST.1) MATCH(RUNCHECK) CLNTUSER('pp12345')
ADDRESS('9.999.999.999')
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123)
By the way, I tried this first without the quotes around the value in the
CLNTUSER field and got "ChlAuth not found". I guess this would be the MQSC
display command folding my ID from lowercase to uppercase and PP12345 not
matching pp12345, so the display command didn't get a hit in that case. But
I do believe its lowercase being used all around during execution.
I'm just puzzled why everything works normally this morning.
Neil,
I agree with you that its trivial to set any ID you want as a client. We
will be using Captialware's Security Exit to do real authentication of the
client on the other end, then using mapping rules to have the connection run
as the ID we want.
Peter Potkay
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Costa, D. (Damian)
Sent: Friday, October 11, 2013 6:17 AM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: Cannot get CHLAUTH Client ID Mapping to work
We've had issues with this before and it turns out that at the domain level
the account is identified by uppercase values instead of lower case .
What happens if you add a chl auth rule with your clntuser in upper case?
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO
Architecture + Engineering)
Sent: 11 October 2013 01:48 AM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Cannot get CHLAUTH Client ID Mapping to work
My client is MQ 7.5.0.2 on a Windows 7 desktop.
The Queue Manager is MQ 7.5.0.2 on a RHEL 6.4 server.
CHLAUTH is enabled.
DISPLAY QMGR CHLAUTH CMDLEVEL
AMQ8408: Display Queue Manager details.
QMNAME(MYQM) CHLAUTH(ENABLED)
CMDLEVEL(750)
Here's the MQ Client channel I'm testing with on my Lab server.
DIS CHANNEL(PETER.TEST.1) ALL
AMQ8414: Display Channel details.
CHANNEL(PETER.TEST.1) CHLTYPE(SVRCONN)
ALTDATE(2013-10-10) ALTTIME(18.51.26)
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) DISCINT(0)
HBINT(30) KAINT(AUTO)
MAXINST(999999999) MAXINSTC(999999999)
MAXMSGL(104857600) MCAUSER(BOGUS_ID_123)
MONCHL(QMGR) RCVDATA( )
RCVEXIT( ) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SHARECNV(10)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) TRPTYPE(TCP)
And here is my CHLAUTH rule.
DISPLAY CHLAUTH (PETER.TEST.1) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(PETER.TEST.1) TYPE(USERMAP)
DESCR( ) CUSTOM( )
ADDRESS( ) CLNTUSER(pp12345)
MCAUSER(abc123) USERSRC(MAP)
ALTDATE(2013-10-10) ALTTIME(18.58.23)
I am logged into my PC as pp12345. And every time I connect to this queue
manager over the PETER.TEST.1 channel the ID the channel runs as is
BOGUS_ID_123. MQRC 2035. Authority Event message shows BOGUS_ID_123. Why is
the CHLAUTH rule not kicking in and changing the connection to run as
abc123?
If I blank out the MCAUSER on the channel, then I connect as pp12345. I
happen to have access to some queues on this QM as this pp12345 ID and I can
open those queues. If I do a channel status it shows me running as pp12345,
not abc123 (see below). If I try and open some other queues I don't have
access to, MQRC 2035 and the Authority Event message shows the pp12345 ID.
Again, why is the CHLAUTH rule not kicking in and changing my connection to
abc123?
Nothing in the queue manager error logs.
display chstatus(PETER.TEST.1) all
AMQ8417: Display Channel Status details.
CHANNEL(PETER.TEST.1) CHLTYPE(SVRCONN)
BUFSRCVD(9) BUFSSENT(8)
BYTSRCVD(1628) BYTSSENT(1444)
CHSTADA(2013-10-10) CHSTATI(19.42.48)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(10.147.130.226) CURRENT
EXITTIME(0,0) HBINT(30)
JOBNAME(0000B7EF00000F73) LOCLADDR(::ffff:99.111.222.99(1414))
LSTMSGDA(2013-10-10) LSTMSGTI(19.42.49)
MCASTAT(RUNNING) MCAUSER(pp12345)
MONCHL(LOW) MSGS(2)
RAPPLTAG(ebSphere MQ\bin\amqsputc.exe)
SSLCERTI( ) SSLKEYDA( )
SSLKEYTI( ) SSLPEER( )
SSLRKEYS(0) STATUS(RUNNING)
STOPREQ(NO) SUBSTATE(RECEIVE)
CURSHCNV(1) MAXSHCNV(10)
RVERSION(07050002) RPRODUCT(MQCC)
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ <http://www.nedbank.co.za/terms/DirectorsNedbank.htm>
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ <http://www.nedbank.co.za/terms/EmailDisclaimer.htm>
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ <http://www.nedbank.co.za/terms/DirectorsNedbank.htm>
http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ <http://www.nedbank.co.za/terms/EmailDisclaimer.htm>
http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
_____
List Archive <http://listserv.meduniwien.ac.at/archives/mqser-l.html> -
Manage Your List Settings
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
Unsubscribe
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries>
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at http://www.lsoft.com
<http://www.lsoft.com/resources/manuals.asp>
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html