From mus3 at lehigh.edu Tue Jun 22 17:01:37 2021 From: mus3 at lehigh.edu (Munroe Sollog) Date: Tue, 22 Jun 2021 13:01:37 -0400 Subject: [tac_plus] DCNM tacacs roles Message-ID: According to the Cisco documentation, DCNM expects the role of 'network-admin' to be supplied to grant a user administrator privileges. I was able to provide that role using this config: service = exec { priv-lvl = 15 cisco-av-pair:shell:roles= "network-admin" #optional shell:roles = "network-admin" } However, this causes my switches to balk. I'm trying to convert that to an "optional" parameter as you can see in the commented line. However I am not having any success. I have been trying to confirm that DCNM is actually requesting the role attribute, but none of my debug commands or packet captures seem to make that clear. Here is some debug output of both the authentication and authorization phase. Any help would be appreciated. Thanks. root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C /etc/tacacs+/tac_plus.conf -g -d24 Reading config Version F4.0.4.27a Initialized 1 tac_plus server F4.0.4.27a starting socket FD 4 AF 2 uid=0 euid=0 gid=0 egid=0 s=-178230864 connect from 192.168.1.248 [192.168.1.248] 192.168.1.248 : fd 5 eof (connection closed) Read -1 bytes from 192.168.1.248 , expecting 12 connect from 192.168.1.248 [192.168.1.248] login query for 'mus3' port 49 from 192.168.1.248 accepted connect from 192.168.1.248 [192.168.1.248] Start authorization request do_author: user='mus3' user 'mus3' found mus3 may run an unlimited number of sessions exec authorization request for mus3 exec is explicitly permitted by line 226 nas:service=shell (passed thru) nas:protocol=ip (passed thru) nas:cmd= (passed thru) nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) nas:shell:roles* svr:shell:roles*network-admin -> replace with shell:roles*network-admin (h) nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) replaced 2 args authorization query for 'mus3' 49 from 192.168.1.248 accepted -- Munroe Sollog (He/Him/His) Senior Network Engineer munroe at lehigh.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mus3 at lehigh.edu Tue Jun 22 17:59:55 2021 From: mus3 at lehigh.edu (Munroe Sollog) Date: Tue, 22 Jun 2021 13:59:55 -0400 Subject: [tac_plus] Cisco DCNM tacacs roles Message-ID: According to the Cisco documentation, DCNM expects the role of 'network-admin' to be supplied to grant a user administrator privileges. I was able to provide that role using this config: service = exec { priv-lvl = 15 cisco-av-pair:shell:roles= "network-admin" #optional shell:roles = "network-admin" } However, this causes my switches to balk. I'm trying to convert that to an "optional" parameter as you can see in the commented line. However I am not having any success. I have been trying to confirm that DCNM is actually requesting the role attribute, but none of my debug commands or packet captures seem to make that clear. Here is some debug output of both the authentication and authorization phase. Any help would be appreciated. Thanks. root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C /etc/tacacs+/tac_plus.conf -g -d24 Reading config Version F4.0.4.27a Initialized 1 tac_plus server F4.0.4.27a starting socket FD 4 AF 2 uid=0 euid=0 gid=0 egid=0 s=-178230864 connect from 192.168.1.248 [192.168.1.248] 192.168.1.248 : fd 5 eof (connection closed) Read -1 bytes from 192.168.1.248 , expecting 12 connect from 192.168.1.248 [192.168.1.248] login query for 'mus3' port 49 from 192.168.1.248 accepted connect from 192.168.1.248 [192.168.1.248] Start authorization request do_author: user='mus3' user 'mus3' found mus3 may run an unlimited number of sessions exec authorization request for mus3 exec is explicitly permitted by line 226 nas:service=shell (passed thru) nas:protocol=ip (passed thru) nas:cmd= (passed thru) nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) nas:shell:roles* svr:shell:roles*network-admin -> replace with shell:roles*network-admin (h) nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) replaced 2 args authorization query for 'mus3' 49 from 192.168.1.248 accepted -- Munroe Sollog (He/Him/His) Senior Network Engineer munroe at lehigh.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Tue Jun 22 19:23:27 2021 From: heas at shrubbery.net (heasley) Date: Tue, 22 Jun 2021 19:23:27 +0000 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: Tue, Jun 22, 2021 at 01:01:37PM -0400, Munroe Sollog: > According to the Cisco documentation, DCNM expects the role of > 'network-admin' to be supplied to grant a user administrator privileges. I > was able to provide that role using this config: > > service = exec { > > priv-lvl = 15 > > cisco-av-pair:shell:roles= "network-admin" > > #optional shell:roles = "network-admin" > > > } > > However, this causes my switches to balk. I'm trying to convert that to an > "optional" parameter as you can see in the commented line. However I am > not having any success. I have been trying to confirm that DCNM is > actually requesting the role attribute, but none of my debug commands or > packet captures seem to make that clear. Here is some debug output of both > the authentication and authorization phase. Any help would be > appreciated. Thanks. There is no "request" of the attribute. The attribute is passed with an authorization reply. I suspect that you have some other configuration error. > root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C /etc/tacacs+/tac_plus.conf > -g -d24 > Reading config > Version F4.0.4.27a Initialized 1 > tac_plus server F4.0.4.27a starting > socket FD 4 AF 2 > uid=0 euid=0 gid=0 egid=0 s=-178230864 > connect from 192.168.1.248 [192.168.1.248] > 192.168.1.248 : fd 5 eof (connection closed) > Read -1 bytes from 192.168.1.248 , expecting 12 > connect from 192.168.1.248 [192.168.1.248] > login query for 'mus3' port 49 from 192.168.1.248 accepted > connect from 192.168.1.248 [192.168.1.248] > Start authorization request > do_author: user='mus3' > user 'mus3' found > mus3 may run an unlimited number of sessions > exec authorization request for mus3 > exec is explicitly permitted by line 226 > nas:service=shell (passed thru) > nas:protocol=ip (passed thru) > nas:cmd= (passed thru) > nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) > nas:shell:roles* svr:shell:roles*network-admin -> replace with > shell:roles*network-admin (h) > nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) > replaced 2 args > authorization query for 'mus3' 49 from 192.168.1.248 accepted > > > > -- > Munroe Sollog (He/Him/His) > Senior Network Engineer > munroe at lehigh.edu > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > _______________________________________________ > tac_plus mailing list > tac_plus at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/tac_plus From mus3 at lehigh.edu Tue Jun 22 19:26:20 2021 From: mus3 at lehigh.edu (Munroe Sollog) Date: Tue, 22 Jun 2021 15:26:20 -0400 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: I thought optional pairs are only sent to the device if they are requested. On Tue, Jun 22, 2021 at 3:23 PM heasley wrote: > Tue, Jun 22, 2021 at 01:01:37PM -0400, Munroe Sollog: > > According to the Cisco documentation, DCNM expects the role of > > 'network-admin' to be supplied to grant a user administrator > privileges. I > > was able to provide that role using this config: > > > > service = exec { > > > > priv-lvl = 15 > > > > cisco-av-pair:shell:roles= "network-admin" > > > > #optional shell:roles = "network-admin" > > > > > > } > > > > However, this causes my switches to balk. I'm trying to convert that to > an > > "optional" parameter as you can see in the commented line. However I am > > not having any success. I have been trying to confirm that DCNM is > > actually requesting the role attribute, but none of my debug commands or > > packet captures seem to make that clear. Here is some debug output of > both > > the authentication and authorization phase. Any help would be > > appreciated. Thanks. > > There is no "request" of the attribute. The attribute is passed with > an authorization reply. > > I suspect that you have some other configuration error. > > > root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C > /etc/tacacs+/tac_plus.conf > > -g -d24 > > Reading config > > Version F4.0.4.27a Initialized 1 > > tac_plus server F4.0.4.27a starting > > socket FD 4 AF 2 > > uid=0 euid=0 gid=0 egid=0 s=-178230864 > > connect from 192.168.1.248 [192.168.1.248] > > 192.168.1.248 : fd 5 eof (connection closed) > > Read -1 bytes from 192.168.1.248 , expecting 12 > > connect from 192.168.1.248 [192.168.1.248] > > login query for 'mus3' port 49 from 192.168.1.248 accepted > > connect from 192.168.1.248 [192.168.1.248] > > Start authorization request > > do_author: user='mus3' > > user 'mus3' found > > mus3 may run an unlimited number of sessions > > exec authorization request for mus3 > > exec is explicitly permitted by line 226 > > nas:service=shell (passed thru) > > nas:protocol=ip (passed thru) > > nas:cmd= (passed thru) > > nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) > > nas:shell:roles* svr:shell:roles*network-admin -> replace with > > shell:roles*network-admin (h) > > nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) > > replaced 2 args > > authorization query for 'mus3' 49 from 192.168.1.248 accepted > > > > > > > > -- > > Munroe Sollog (He/Him/His) > > Senior Network Engineer > > munroe at lehigh.edu > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20210622/4be317c5/attachment.htm > > > > _______________________________________________ > > tac_plus mailing list > > tac_plus at www.shrubbery.net > > https://www.shrubbery.net/mailman/listinfo/tac_plus > -- Munroe Sollog (He/Him/His) Senior Network Engineer munroe at lehigh.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Tue Jun 22 20:19:45 2021 From: heas at shrubbery.net (heasley) Date: Tue, 22 Jun 2021 20:19:45 +0000 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: Tue, Jun 22, 2021 at 03:26:20PM -0400, Munroe Sollog: > I thought optional pairs are only sent to the device if they are requested. they should always be sent. It is the device's choice whether to act upon optional AVPs. The device MUST act upon non-optional AVPs; this is why an AVP that is unknown to a device often causes an error on/from the device. You might find an external authorization script useful for debugging or even for more flexibility in AVP manipulation. user = auth1 { before authorization "/path/pre_authorize $user $port $address" after authorization "/path/post_authorize $user $port $status" } > On Tue, Jun 22, 2021 at 3:23 PM heasley wrote: > > > Tue, Jun 22, 2021 at 01:01:37PM -0400, Munroe Sollog: > > > According to the Cisco documentation, DCNM expects the role of > > > 'network-admin' to be supplied to grant a user administrator > > privileges. I > > > was able to provide that role using this config: > > > > > > service = exec { > > > > > > priv-lvl = 15 > > > > > > cisco-av-pair:shell:roles= "network-admin" > > > > > > #optional shell:roles = "network-admin" > > > > > > > > > } > > > > > > However, this causes my switches to balk. I'm trying to convert that to > > an > > > "optional" parameter as you can see in the commented line. However I am > > > not having any success. I have been trying to confirm that DCNM is > > > actually requesting the role attribute, but none of my debug commands or > > > packet captures seem to make that clear. Here is some debug output of > > both > > > the authentication and authorization phase. Any help would be > > > appreciated. Thanks. > > > > There is no "request" of the attribute. The attribute is passed with > > an authorization reply. > > > > I suspect that you have some other configuration error. > > > > > root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C > > /etc/tacacs+/tac_plus.conf > > > -g -d24 > > > Reading config > > > Version F4.0.4.27a Initialized 1 > > > tac_plus server F4.0.4.27a starting > > > socket FD 4 AF 2 > > > uid=0 euid=0 gid=0 egid=0 s=-178230864 > > > connect from 192.168.1.248 [192.168.1.248] > > > 192.168.1.248 : fd 5 eof (connection closed) > > > Read -1 bytes from 192.168.1.248 , expecting 12 > > > connect from 192.168.1.248 [192.168.1.248] > > > login query for 'mus3' port 49 from 192.168.1.248 accepted > > > connect from 192.168.1.248 [192.168.1.248] > > > Start authorization request > > > do_author: user='mus3' > > > user 'mus3' found > > > mus3 may run an unlimited number of sessions > > > exec authorization request for mus3 > > > exec is explicitly permitted by line 226 > > > nas:service=shell (passed thru) > > > nas:protocol=ip (passed thru) > > > nas:cmd= (passed thru) > > > nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) > > > nas:shell:roles* svr:shell:roles*network-admin -> replace with > > > shell:roles*network-admin (h) > > > nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) > > > replaced 2 args > > > authorization query for 'mus3' 49 from 192.168.1.248 accepted > > > > > > > > > > > > -- > > > Munroe Sollog (He/Him/His) > > > Senior Network Engineer > > > munroe at lehigh.edu > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: < > > http://www.shrubbery.net/pipermail/tac_plus/attachments/20210622/4be317c5/attachment.htm > > > > > > _______________________________________________ > > > tac_plus mailing list > > > tac_plus at www.shrubbery.net > > > https://www.shrubbery.net/mailman/listinfo/tac_plus > > > -- > Munroe Sollog (He/Him/His) > Senior Network Engineer > munroe at lehigh.edu From mus3 at lehigh.edu Wed Jun 23 16:04:54 2021 From: mus3 at lehigh.edu (Munroe Sollog) Date: Wed, 23 Jun 2021 12:04:54 -0400 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: I don't want to get distracted from my actual problem, but after reading this: https://shrubbery.net/pipermail/tac_plus/2012-January/001048.html I thought the optional AVPs are not sent unless requested. Either way, I'm trying to figure out why works but does not work. Thanks. On Tue, Jun 22, 2021 at 4:19 PM heasley wrote: > Tue, Jun 22, 2021 at 03:26:20PM -0400, Munroe Sollog: > > I thought optional pairs are only sent to the device if they are > requested. > > they should always be sent. It is the device's choice whether to > act upon optional AVPs. The device MUST act upon non-optional AVPs; > this is why an AVP that is unknown to a device often causes an error > on/from the device. > > You might find an external authorization script useful for debugging > or even for more flexibility in AVP manipulation. > > user = auth1 { > before authorization "/path/pre_authorize $user $port $address" > after authorization "/path/post_authorize $user $port $status" > } > > > On Tue, Jun 22, 2021 at 3:23 PM heasley wrote: > > > > > Tue, Jun 22, 2021 at 01:01:37PM -0400, Munroe Sollog: > > > > According to the Cisco documentation, DCNM expects the role of > > > > 'network-admin' to be supplied to grant a user administrator > > > privileges. I > > > > was able to provide that role using this config: > > > > > > > > service = exec { > > > > > > > > priv-lvl = 15 > > > > > > > > cisco-av-pair:shell:roles= "network-admin" > > > > > > > > #optional shell:roles = "network-admin" > > > > > > > > > > > > } > > > > > > > > However, this causes my switches to balk. I'm trying to convert > that to > > > an > > > > "optional" parameter as you can see in the commented line. However > I am > > > > not having any success. I have been trying to confirm that DCNM is > > > > actually requesting the role attribute, but none of my debug > commands or > > > > packet captures seem to make that clear. Here is some debug output > of > > > both > > > > the authentication and authorization phase. Any help would be > > > > appreciated. Thanks. > > > > > > There is no "request" of the attribute. The attribute is passed with > > > an authorization reply. > > > > > > I suspect that you have some other configuration error. > > > > > > > root at rover:/etc/tacacs+# /usr/sbin/tac_plus -C > > > /etc/tacacs+/tac_plus.conf > > > > -g -d24 > > > > Reading config > > > > Version F4.0.4.27a Initialized 1 > > > > tac_plus server F4.0.4.27a starting > > > > socket FD 4 AF 2 > > > > uid=0 euid=0 gid=0 egid=0 s=-178230864 > > > > connect from 192.168.1.248 [192.168.1.248] > > > > 192.168.1.248 : fd 5 eof (connection closed) > > > > Read -1 bytes from 192.168.1.248 , expecting 12 > > > > connect from 192.168.1.248 [192.168.1.248] > > > > login query for 'mus3' port 49 from 192.168.1.248 accepted > > > > connect from 192.168.1.248 [192.168.1.248] > > > > Start authorization request > > > > do_author: user='mus3' > > > > user 'mus3' found > > > > mus3 may run an unlimited number of sessions > > > > exec authorization request for mus3 > > > > exec is explicitly permitted by line 226 > > > > nas:service=shell (passed thru) > > > > nas:protocol=ip (passed thru) > > > > nas:cmd= (passed thru) > > > > nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i) > > > > nas:shell:roles* svr:shell:roles*network-admin -> replace with > > > > shell:roles*network-admin (h) > > > > nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k) > > > > replaced 2 args > > > > authorization query for 'mus3' 49 from 192.168.1.248 accepted > > > > > > > > > > > > > > > > -- > > > > Munroe Sollog (He/Him/His) > > > > Senior Network Engineer > > > > munroe at lehigh.edu > > > > -------------- next part -------------- > > > > An HTML attachment was scrubbed... > > > > URL: < > > > > http://www.shrubbery.net/pipermail/tac_plus/attachments/20210622/4be317c5/attachment.htm > > > > > > > > _______________________________________________ > > > > tac_plus mailing list > > > > tac_plus at www.shrubbery.net > > > > https://www.shrubbery.net/mailman/listinfo/tac_plus > > > > > -- > > Munroe Sollog (He/Him/His) > > Senior Network Engineer > > munroe at lehigh.edu > -- Munroe Sollog (He/Him/His) Senior Network Engineer munroe at lehigh.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekoons5159 at gmail.com Wed Jun 23 12:12:44 2021 From: ekoons5159 at gmail.com (Eric Koons) Date: Wed, 23 Jun 2021 12:12:44 +0000 Subject: [tac_plus] Set different privilege level per device Message-ID: Is there a way to set a different privilege per device using the same login credentials? So for example our switches and routers require a privilege level of 15, but we have an Optical transport system where the superuser is privilege level 3. The work around at the moment is to use 2 different login credentials. I?d like to see if I could use a single login credential and have tacacs send the correct privilege level based upon some determined characteristic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schmidt at wyo.gov Wed Jun 23 18:01:33 2021 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Wed, 23 Jun 2021 13:01:33 -0500 Subject: [tac_plus] Set different privilege level per device In-Reply-To: References: Message-ID: An after authentication script will do that. For instance, this one: https://github.com/helpdeskdan/do_auth On Wed, Jun 23, 2021 at 11:49 AM Eric Koons wrote: > Is there a way to set a different privilege per device using the same > login credentials? So for example our switches and routers require a > privilege level of 15, but we have an Optical transport system where the > superuser is privilege level 3. The work around at the moment is to use 2 > different login credentials. I?d like to see if I could use a single login > credential and have tacacs send the correct privilege level based upon some > determined characteristic. > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.shrubbery.net/pipermail/tac_plus/attachments/20210623/9f6e3cbe/attachment.htm > > > _______________________________________________ > tac_plus mailing list > tac_plus at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/tac_plus > -- E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: From heas at shrubbery.net Fri Jun 25 20:37:31 2021 From: heas at shrubbery.net (heasley) Date: Fri, 25 Jun 2021 20:37:31 +0000 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: Wed, Jun 23, 2021 at 12:04:54PM -0400, Munroe Sollog: > I don't want to get distracted from my actual problem, but after reading > this: > https://shrubbery.net/pipermail/tac_plus/2012-January/001048.html > I thought the optional AVPs are not sent unless requested. Either way, I'm > trying to figure out why works > but does not work. I went through the code, and it indeed does not return any AVPs that were not received, though it may change their value. My recollection was that it returned them; sorry. Without code changes, there is currently no way to force sending an AVP from the config that was not received, except by using a before or after authoritzation script. eg: #! /bin/sh while read x; do case $x in cmd*) continue; ;; *) echo $x esac done # send/add the unsolicited avp echo 'idletime=2' exit 2 However, what I have discovered is that the rfc is vague about what the client should do if it receives an optional AVP that it does not support. It say ignore optionals, but does not say MUST, and at another point it vaguely says that it must use replaced AVPs without specifing what to do with optionals. In my mind, it should ignore it, but IOS classic and XE fail, unless it is one of the AVPs specified in rfc8907 S8.2. For this reason, one of these scripts is probably the best solution compared to code changes, as it allows the response to more easily be tailored to the client, and do_auth.py might work for you. YMMV, you will have to test your particular client. It seems unlikely for this unspecificity to be corrected due to the history of this rfc and implementations. From daniel.schmidt at wyo.gov Sat Jun 26 01:55:55 2021 From: daniel.schmidt at wyo.gov (Daniel Schmidt) Date: Fri, 25 Jun 2021 20:55:55 -0500 Subject: [tac_plus] DCNM tacacs roles In-Reply-To: References: Message-ID: That sounds a lot like the Nexus, which worked as so: https://www.tacacs.org/tacacsplus/2011/10/27/cisco-nexus You may have luck with my after-authentication script: https://github.com/helpdeskdan/do_auth Let me know if you find it useful. On Fri, Jun 25, 2021 at 3:37 PM heasley wrote: > Wed, Jun 23, 2021 at 12:04:54PM -0400, Munroe Sollog: > > I don't want to get distracted from my actual problem, but after reading > > this: > > https://shrubbery.net/pipermail/tac_plus/2012-January/001048.html > > I thought the optional AVPs are not sent unless requested. Either way, > I'm > > trying to figure out why > works > > but does not work. > > I went through the code, and it indeed does not return any AVPs that > were not received, though it may change their value. My recollection > was that it returned them; sorry. > > Without code changes, there is currently no way to force sending an > AVP from the config that was not received, except by using a before > or after authoritzation script. eg: > > #! /bin/sh > while read x; do > case $x in > cmd*) > continue; > ;; > *) > echo $x > esac > done > # send/add the unsolicited avp > echo 'idletime=2' > exit 2 > > However, what I have discovered is that the rfc is vague about what the > client should do if it receives an optional AVP that it does not support. > It say ignore optionals, but does not say MUST, and at another point it > vaguely says that it must use replaced AVPs without specifing what to do > with optionals. In my mind, it should ignore it, but IOS classic and XE > fail, unless it is one of the AVPs specified in rfc8907 S8.2. > > For this reason, one of these scripts is probably the best solution > compared to code changes, as it allows the response to more easily be > tailored to the client, and do_auth.py might work for you. > > YMMV, you will have to test your particular client. > > It seems unlikely for this unspecificity to be corrected due to the history > of this rfc and implementations. > > _______________________________________________ > tac_plus mailing list > tac_plus at www.shrubbery.net > https://www.shrubbery.net/mailman/listinfo/tac_plus > -- E-Mail to and from me, in connection with the transaction of public business, is subject to the Wyoming Public Records Act and may be disclosed to third parties. -------------- next part -------------- An HTML attachment was scrubbed... URL: