Re: [OpenAFS] Kerberos + Windows
The service principal details are fuzzy now – we haven’t touched them in a long time – but we use a krb.conf to specify two authentication realms, neither of which matches the cell name. MIT KDC and Active Directory, with non-overlapping principal names. It works great, and the only issue getting it set up was explaining to the AD Domain admins why we needed this strange afs/mydomain@ad.mydomain.com<mailto:afs/mydomain@ad.mydomain.com> entry, and get them to promise not to expire it like other special service accounts we have. Richard From: openafs-info-ad...@openafs.org on behalf of Ken Hornstein Date: Wednesday, August 24, 2022 at 9:22 PM To: Benjamin Kaduk Cc: Ben Huntsman , openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows >On Wed, Aug 24, 2022 at 04:53:11PM +, Ben Huntsman wrote: >> ktpass /princ afs/mydomain@ad.mydomain.com /mapuser srvAFS /mapop add >> /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt > >When the name of the AFS cell does not match the name of the kerberos >realm, the OpenAFS configuration needs to include a krb.conf file to >specify the realm the AFS servers use for authentication. Note that this >is completely different from the kerberos krb5.conf file and lives in a >different location. Ooof, I totally missed that. Yes, that would do it. --Ken ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kerberos + Windows
Hi there!
Thanks for the replies!
I got it working!!!
> In addition to the key version number you also need to know the encryption
> type used to
> encrypt the service private portion of the afs/mydomain@ad.mydomain.com
> service
> ticket. It is that encryption type which does not need to match either the
> encryption type
> used to encrypt the client private portion of the ticket or the session key
> which needs to
> match the keys added via asetkey.
Ah! This is interesting:
# kinit adUser
Password for adu...@ad.mydomain.com:
# klist -e
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: adu...@ad.mydomain.com
Valid starting ExpiresService principal
08/24/22 21:49:12 08/25/22 07:49:12 krbtgt/ad.mydomain@ad.mydomain.com
renew until 08/25/22 21:49:10, Etype (skey, tkt):
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
# aklog
# klist -e
Ticket cache: FILE:/var/krb5/security/creds/krb5cc_0
Default principal: adu...@ad.mydomain.com
Valid starting ExpiresService principal
08/24/22 21:49:12 08/25/22 07:49:12 krbtgt/ad.mydomain@ad.mydomain.com
renew until 08/25/22 21:49:10, Etype (skey, tkt):
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
08/24/22 21:49:26 08/25/22 07:49:12 afs/mydomain@ad.mydomain.com
renew until 08/25/22 21:49:10, Etype (skey, tkt): arcfour-hmac,
arcfour-hmac
After running aklog I have one that is using arcfour-hmac. Didn't expect that.
I had only the AES types in my keytab, and hadn't run an asetkey for that one.
I had the original keytab pre-edits to remove all but the AES types, and I
brought that back over and removed only DES, leaving the arcfour-hmac one, and
then ran asetkey for it using the encryption type 23, bounced the server, and
it worked!!
I also did end up adding in the "mydomain.com" and ".mydomain.com" entries in
krb5.conf, and I put in a file /opt/openafs/etc/openafs/server/krb.conf with
only one line that says "AD.MYDOMAIN.COM".
I'm glad this all working now!! Thank you all so much for the help!!
-Ben
From: Jeffrey E Altman
Sent: Wednesday, August 24, 2022 6:49 PM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] Kerberos + Windows
On 8/24/2022 12:53 PM, Ben Huntsman
(b...@huntsmans.net<mailto:b...@huntsmans.net>) wrote:
Here's some configuration info:
Let's say my cell is going to be mydomain.com. My Active Directory is
ad.mydomain.com, and my AFS service account is srvAFS.
When installing Active Directory for a domain "mydomain.com" it is best if the
Active Directory domain is "MYDOMAIN.COM" instead of "AD.MYDOMAIN.COM". This
is because Kerberos clients will attempt to use the DNS name of the host as the
Kerberos realm name. The use of "AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM"
naming is common only in cases where there is a pre-existing Kerberos realm for
"MYDOMAIN.COM".
Here's my krb5.conf:
[libdefaults]
default_realm = AD.MYDOMAIN.COM
default_keytab_name =
[FILE:/etc/krb5/krb5.keytab]FILE:/etc/krb5/krb5.keytab
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
[realms]
AD.MYDOMAIN.COM = {
kdc = ad.mydomain.com:88
admin_server = ad.mydomain.com:749
default_domain = ad.mydomain.com
}
[domain_realm]
.ad.mydomain.com = AD.MYDOMAIN.COM
ad.mydomain.com = AD.MYDOMAIN.COM
You also need to add
.mydomain.com = AD.MYDOMAIN.COM
mydomain.com = AD.MYDOMAIN.COM
since the Kerberos realm is not the same as the DNS domain name used for the
AFS service principal.
[logging]
kdc = [FILE:/var/krb5/log/krb5kdc.log]FILE:/var/krb5/log/krb5kdc.log
admin_server =
[FILE:/var/krb5/log/kadmin.log]FILE:/var/krb5/log/kadmin.log
kadmin_local =
[FILE:/var/krb5/log/kadmin_local.log]FILE:/var/krb5/log/kadmin_local.log
default = [FILE:/var/krb5/log/krb5lib.log]FILE:/var/krb5/log/krb5lib.log
I then created the service account srvAFS, and extracted a keytab on the Domain
Controller using the following command:
ktpass /princ
afs/mydomain@ad.mydomain.com<mailto:afs/mydomain@ad.mydomain.com>
/mapuser srvAFS /mapop add /out rxkad.keytab +rndpass /crypto all /ptype
KRB5_NT_PRINCIPAL +dumpsalt
The use of
"afs/mydomain@ad.mydomain.com"<mailto:afs/mydomain@ad.mydomain.com> is
correct. The "a...@ad.mydomain.com"<mailto:a...@ad.mydomain.com> service
principal name should no longer be used and must never be used with Active
Directory.
I verified that the account did not have the "Use only Kerberos DES encryption
types for this account" box checked. I then copied the rxkad.keytab over to
the UNIX host. I built OpenAFS with a p
Re: [OpenAFS] Kerberos + Windows
On 8/24/2022 12:53 PM, Ben Huntsman (b...@huntsmans.net) wrote:
Here's some configuration info:
Let's say my cell is going to be mydomain.com. My Active Directory
is ad.mydomain.com, and my AFS service account is srvAFS.
When installing Active Directory for a domain "mydomain.com" it is best
if the Active Directory domain is "MYDOMAIN.COM" instead of
"AD.MYDOMAIN.COM". This is because Kerberos clients will attempt to use
the DNS name of the host as the Kerberos realm name. The use of
"AD.MYDOMAIN.COM" or "WIN.MYDOMAIN.COM" naming is common only in cases
where there is a pre-existing Kerberos realm for "MYDOMAIN.COM".
Here's my krb5.conf:
[libdefaults]
default_realm = AD.MYDOMAIN.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
[realms]
AD.MYDOMAIN.COM = {
kdc = ad.mydomain.com:88
admin_server = ad.mydomain.com:749
default_domain = ad.mydomain.com
}
[domain_realm]
.ad.mydomain.com = AD.MYDOMAIN.COM
ad.mydomain.com = AD.MYDOMAIN.COM
You also need to add
.mydomain.com = AD.MYDOMAIN.COM
mydomain.com = AD.MYDOMAIN.COM
since the Kerberos realm is not the same as the DNS domain name used for
the AFS service principal.
[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
kadmin_local = FILE:/var/krb5/log/kadmin_local.log
default = FILE:/var/krb5/log/krb5lib.log
I then created the service account srvAFS, and extracted a keytab on
the Domain Controller using the following command:
ktpass /princ afs/mydomain@ad.mydomain.com /mapuser srvAFS /mapop
add /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL
+dumpsalt
The use of "afs/mydomain@ad.mydomain.com" is correct. The
"a...@ad.mydomain.com" service principal name should no longer be used
and must never be used with Active Directory.
I verified that the account did not have the "Use only Kerberos DES
encryption types for this account" box checked. I then copied the
rxkad.keytab over to the UNIX host. I built OpenAFS with a prefix of
/opt/openafs, so I put the keytab in /opt/openafs/etc/openafs/server
I used ktutil to delete the two des entries in the keytab. ktutil
indicates that the KVNO is 5.
I then added the keys to OpenAFS using the command:
asetkey add rxkad_krb5 5 17
/opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com
asetkey add rxkad_krb5 5 18
/opt/openafs/etc/openafs/server/rxkad.keytab afs/mydomain.com
For an Active Directory realm you most likely also need to add rc4-hmac,
enctype 23.
Did the above "asetkey" commands succeed? Since the cell is named
"mydomain.com" I would expect asetkey to expand "afs/mydomain.com" to
"afs/mydomain@mydomain.com" which is not going to be present in the
rxkad.keytab file.
What is the output of "asetkey list" after the above commands were executed?
But things aren't quite working:
# ls /afs
afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded
(rxkad error=19270408, server 192.168.0.114)
ls: /afs: The file access permissions do not allow the specified action.
# kvno adu...@ad.mydomain.com
kvno: Server not found in Kerberos database while getting credentials
for adu...@ad.mydomain.com
This is not expected to work.
# vos listvol myserver
Could not fetch the list of partitions from the server
rxk: ticket contained unknown key version number
Error in vos listvol command.
rxk: ticket contained unknown key version number
19270408 = rxk: ticket contained unknown key version number
It means the OpenAFS servers are not finding the expected key entry.
There is not a match for the combination of enctype and key version
number and name.
# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab
afs/mydomain@ad.mydomain.com
The above command is using the afs/mydomain@ad.mydomain.com keytab
entry to obtain a client Ticket Granting Ticket. I doubt that is what
you intended.
Instead you wanted to "kinit" using a client principal and then execute
the kvno command below.
# kvno afs/mydomain@ad.mydomain.com
afs/mydomain@ad.mydomain.com: kvno = 5
In addition to the key version number you also need to know the
encryption type used to encrypt the service private portion of the
afs/mydomain@ad.mydomain.com service ticket. It is that encryption
type which does not need to match either the encryption type used to
encrypt the client private portion of the ticket or the session key
which needs to match the keys added via asetkey.
After adding the keys via "asetkey" did you install KeyFileExt on every
server in the cell?
Did you restart the services or touch the server instance of the
CellServDB file to force the new keys to be loaded?
Did I miss something, or make a mistake
Re: [OpenAFS] Kerberos + Windows
On Wed, Aug 24, 2022 at 04:53:11PM +, Ben Huntsman wrote: > ktpass /princ afs/mydomain@ad.mydomain.com /mapuser srvAFS /mapop add > /out rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt When the name of the AFS cell does not match the name of the kerberos realm, the OpenAFS configuration needs to include a krb.conf file to specify the realm the AFS servers use for authentication. Note that this is completely different from the kerberos krb5.conf file and lives in a different location. -Ben sent from mobile ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kerberos + Windows
Thanks for the reply! > So I'm not the expert on how AD works, so I can't speak for what happens > if you create a service account called _one_ thing and then have a > different principal name. Like, what name ends up in the service > ticket? But, moving on ... I was a little fuzzy on that, but I was under the impression that in my case the serivce principal for AFS has to be called "afs/mydomain.com". Is that not so? Therefore, one could either create an AD account literally called "afs", or, let the ktpass command create a SPN for the account, and let it's name conform to local naming standards. Indeed we can see that the SPN is created, by running setspn on Windows: C:\>setspn -L srvAFS Registered ServicePrincipalNames for CN=srvAFS,OU=Users,DC=ad,DC=mydomain,DC=com: afs/mydomain.com > kvno is used when you already have a Kerberos ticket (with kinit) and you're > getting a service ticket for what you give on the command line. I think > what you want "kinit adUser" and the "kvno afs/mydomain.com". Although > aklog should do the same thing. > > It would be interesting to see what the output of "klist" is after you > do that kinit/kvno command sequence. $ kinit adUser Password for adu...@ad.mydomain.com: $ kvno afs/mydomain.com afs/mydomain@ad.mydomain.com: kvno = 5 $ aklog -d Authenticating to cell mydomain.com (server myserver). Trying to authenticate to user's realm AD.MYDOMAIN.COM. Getting tickets: afs/mydomain@ad.mydomain.com Using Kerberos V5 ticket natively About to resolve name adUser to id in cell mydomain.com. Id 204 Setting tokens. adUser @ mydomain.com $ klist Ticket cache: FILE:/var/krb5/security/creds/krb5cc_204 Default principal: adu...@ad.mydomain.com Valid starting ExpiresService principal 08/24/22 12:28:35 08/24/22 22:28:35 krbtgt/ad.mydomain@ad.mydomain.com renew until 08/25/22 12:28:30 08/24/22 12:28:51 08/24/22 22:28:35 afs/mydomain@ad.mydomain.com renew until 08/25/22 12:28:30 > There is some magic that asetkey does in terms of key version numbering > for rxkad_krb5 but it escapes me now and I suspect that's not your real > problem. I am assuming you've distributed the KeyFile to _all_ of your > AFS servers. This is the first AFS server, so there's no other servers to distribute it to yet. # asetkey list rxkad_krb5 kvno5 enctype 17; key is: blahblahblah rxkad_krb5 kvno5 enctype 18; key is: blahblahblahblahblahblah All done. It seems like it's close but I'm just missing one thing... not quite sure what though. Thank you so much! -Ben From: Ken Hornstein Sent: Wednesday, August 24, 2022 11:42 AM To: Ben Huntsman Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Kerberos + Windows >I then created the service account srvAFS, and extracted a keytab on the >Domain Controller using the following command: So I'm not the expert on how AD works, so I can't speak for what happens if you create a service account called _one_ thing and then have a different principal name. Like, what name ends up in the service ticket? But, moving on ... ># kvno adu...@ad.mydomain.com >kvno: Server not found in Kerberos database while getting credentials for >adu...@ad.mydomain.com kvno is used when you already have a Kerberos ticket (with kinit) and you're getting a service ticket for what you give on the command line. I think what you want "kinit adUser" and the "kvno afs/mydomain.com". Although aklog should do the same thing. It would be interesting to see what the output of "klist" is after you do that kinit/kvno command sequence. There is some magic that asetkey does in terms of key version numbering for rxkad_krb5 but it escapes me now and I suspect that's not your real problem. I am assuming you've distributed the KeyFile to _all_ of your AFS servers. --Ken
Re: [OpenAFS] Kerberos + Windows
>I then created the service account srvAFS, and extracted a keytab on the >Domain Controller using the following command: So I'm not the expert on how AD works, so I can't speak for what happens if you create a service account called _one_ thing and then have a different principal name. Like, what name ends up in the service ticket? But, moving on ... ># kvno adu...@ad.mydomain.com >kvno: Server not found in Kerberos database while getting credentials for >adu...@ad.mydomain.com kvno is used when you already have a Kerberos ticket (with kinit) and you're getting a service ticket for what you give on the command line. I think what you want "kinit adUser" and the "kvno afs/mydomain.com". Although aklog should do the same thing. It would be interesting to see what the output of "klist" is after you do that kinit/kvno command sequence. There is some magic that asetkey does in terms of key version numbering for rxkad_krb5 but it escapes me now and I suspect that's not your real problem. I am assuming you've distributed the KeyFile to _all_ of your AFS servers. --Ken ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kerberos + Windows
Hi there!
Thanks for the replies! Removing the encryption types lines helped, and I
got further. This is MIT Kerberos.
Here's some configuration info:
Let's say my cell is going to be mydomain.com. My Active Directory is
ad.mydomain.com, and my AFS service account is srvAFS. Here's my krb5.conf:
[libdefaults]
default_realm = AD.MYDOMAIN.COM
default_keytab_name = FILE:/etc/krb5/krb5.keytab
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
[realms]
AD.MYDOMAIN.COM = {
kdc = ad.mydomain.com:88
admin_server = ad.mydomain.com:749
default_domain = ad.mydomain.com
}
[domain_realm]
.ad.mydomain.com = AD.MYDOMAIN.COM
ad.mydomain.com = AD.MYDOMAIN.COM
[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
kadmin_local = FILE:/var/krb5/log/kadmin_local.log
default = FILE:/var/krb5/log/krb5lib.log
I then created the service account srvAFS, and extracted a keytab on the Domain
Controller using the following command:
ktpass /princ afs/mydomain@ad.mydomain.com /mapuser srvAFS /mapop add /out
rxkad.keytab +rndpass /crypto all /ptype KRB5_NT_PRINCIPAL +dumpsalt
I verified that the account did not have the "Use only Kerberos DES encryption
types for this account" box checked. I then copied the rxkad.keytab over to
the UNIX host. I built OpenAFS with a prefix of /opt/openafs, so I put the
keytab in /opt/openafs/etc/openafs/server
I used ktutil to delete the two des entries in the keytab. ktutil indicates
that the KVNO is 5.
I then added the keys to OpenAFS using the command:
asetkey add rxkad_krb5 5 17 /opt/openafs/etc/openafs/server/rxkad.keytab
afs/mydomain.com
asetkey add rxkad_krb5 5 18 /opt/openafs/etc/openafs/server/rxkad.keytab
afs/mydomain.com
Now I add an AD user to OpenAFS:
pts createuser -name adUser -id 204 -localauth
pts adduser adUser system:administrators -localauth
And I try to authenticate:
kinit adUser
That gives me a password prompt, and it's accepted. Then I run:
aklog
Also accepted:
# tokens
Tokens held by the Cache Manager:
User's (AFS ID 204) rxkad tokens for mydomain.com [Expires Aug 24 18:27]
--End of list--
But things aren't quite working:
# ls /afs
afs: Tokens for user of AFS id 204 for cell mydomain.com are discarded (rxkad
error=19270408, server 192.168.0.114)
ls: /afs: The file access permissions do not allow the specified action.
# kvno adu...@ad.mydomain.com
kvno: Server not found in Kerberos database while getting credentials for
adu...@ad.mydomain.com
# vos listvol myserver
Could not fetch the list of partitions from the server
rxk: ticket contained unknown key version number
Error in vos listvol command.
rxk: ticket contained unknown key version number
# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab
kinit: Cannot determine realm for host (principal host/myserver.mydomain.com@)
# kinit -kt /opt/openafs/etc/openafs/server/rxkad.keytab
afs/mydomain@ad.mydomain.com
# kvno afs/mydomain@ad.mydomain.com
afs/mydomain@ad.mydomain.com: kvno = 5
Did I miss something, or make a mistake along the way somewhere?
Thank you so much!!
-Ben
From: Jeffrey E Altman
Sent: Wednesday, August 24, 2022 5:02 AM
To: Ben Huntsman; openafs-info@openafs.org
Subject: Re: [OpenAFS] Kerberos + Windows
On 8/23/2022 9:24 PM, Ben Huntsman
(b...@huntsmans.net<mailto:b...@huntsmans.net>) wrote:
Hi guys-
Does anyone have a working krb5.conf that works with Windows 2012 R2 or
newer?
The docs do show how to set up using the new scheme but assume Kerberos, not
AD. I've tried a few different things but I can't seem to get
default_tkt_enctypes and default_tks_enctypes set correctly.
Ben,
A krb5.conf is configuration for an MIT or Heimdal Kerberos client but not for
a Microsoft Windows Kerberos client.
Please clarify which Kerberos client implementation you are configuring.
I agree with Ken that default_tkt_enctypes and default_tks_enctypes should
never be configured on clients.
Jeffrey Altman
Re: [OpenAFS] Kerberos + Windows
On 8/23/2022 9:24 PM, Ben Huntsman (b...@huntsmans.net) wrote: > Hi guys- > Does anyone have a working krb5.conf that works with Windows 2012 > R2 or newer? > > The docs do show how to set up using the new scheme but assume > Kerberos, not AD. I've tried a few different things but I can't seem > to get default_tkt_enctypes and default_tks_enctypes set correctly. > Ben, A krb5.conf is configuration for an MIT or Heimdal Kerberos client but not for a Microsoft Windows Kerberos client. Please clarify which Kerberos client implementation you are configuring. I agree with Ken that default_tkt_enctypes and default_tks_enctypes should never be configured on clients. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: [OpenAFS] Kerberos + Windows
>The docs do show how to set up using the new scheme but assume >Kerberos, not AD. I've tried a few different things but I can't seem >to get default_tkt_enctypes and default_tks_enctypes set correctly. In the normal course of things you never, ever want to put any entries for default_tkt_enctypes and default_tgs_enctypes (I'm assuming that's what you meant for the second one). Just remove them from your krb5.conf and take the defaults. The circumstances where you'd ever want to specify those are very very rare. If there is documentation somewhere that says you SHOULD put something for those entries, let me know and I will personally hunt it down and kill it (we had a problem where people in my larger organization thought it was a good idea to put entries in for those configuration file entries; caused us problems for YEARS). --Ken ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
Re: [OpenAFS] Kerberos + Windows
Hi guys- Does anyone have a working krb5.conf that works with Windows 2012 R2 or newer? The docs do show how to set up using the new scheme but assume Kerberos, not AD. I've tried a few different things but I can't seem to get default_tkt_enctypes and default_tks_enctypes set correctly. Thank you in advance! -Ben
Re: [OpenAFS] Kerberos + Windows
On Tue, Aug 16, 2022 at 04:43:19AM +, Ben Huntsman wrote: > Hi guys- >Does anyone have a recipe for making OpenAFS work with AD 2012 R2 or 2016 > as a KDC? > >I've seen a few articles on using it with 2008 R2, which mostly involve > re-enabling des-cbc-crc on the AD side... Does OpenAFS support the current > schemes like aes256-cts-hmac-sha1-96, and has anyone gotten that to work? > >Or is one better off by setting up their own Kerbreos just for OpenAFS? In the aftermath of https://www.openafs.org/pages/security/OPENAFS-SA-2013-003.txt the state of the art became using current kerberos enctypes for the service principal, with the KDF to get back to fcrypt keys contained within the AFS boundary. The main thing that has come up with using Windows as the KDC is the possible need to disable or trim down the PACs issued for AFS principals ... though in the wake of some of the more recent AD/Kerberos vulnerabilities maybe that is less advisable, I have forgotten the details. https://datatracker.ietf.org/doc/html/draft-kaduk-afs3-rxkad-k5-kdf-00 discuss the protocol details, https://www.openafs.org/pages/security/install-rxkad-k5-1.6.txt talks about the process of converting an existing cell to use the new mechanisms, and http://docs.openafs.org/QuickStartUnix/ has (IIRC) been updated to cover installing with rxkad-k5 from scratch. Hopefully others can chime in if there are more AD-specific bits than just rxkad-k5; I don't actually run any such environments myself. -Ben ___ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
