Update: Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes. I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token. The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055 ----- Original Message ----- From: "Dan Olson" <[email protected]> To: "core-admins" <[email protected]> Cc: "Jini Ramprakash" <[email protected]>, "Robert R. Scott" <[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status I've been on the phone working with cryptocard support all morning. The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional. The users are: cdaley gjordan fischer eholohan I will send updates as soon as I have any. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break. -David On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
Okay, we'll schedule the outage and rebuild for after the break. On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
Craig, Can you tell me the plan for digging into this? -David On 12/22/10 2:36 PM, Craig Stacey wrote:
Okay, we'll schedule the outage and rebuild for after the break.
On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
We've got a multi-pronged approach on this. * Dan's moving the authentications off the VM that is currently serving authentication and back to the primary machine that was serving authentications before. * We're trying to get ALCF to make some changes in the nagios-cmd (IIRC) user that's spamming the logs and making it difficult for us to troubleshoot the issue, but the tickets haven't gone anywhere. I've asked Dan to talk to the admins in person to make this happen. If none of these are enlightening, we're going to (with ALCF) schedule a brief downtime next week to follow the rebuild steps recommended by CryptoCard in helping to solve this problem. We're also investigating an alternate proxy configuration (or removing proxies) should the rebuild not work. On Jan 7, 2011, at 2:35 PM, David E. Martin wrote:
Craig, Can you tell me the plan for digging into this?
-David
On 12/22/10 2:36 PM, Craig Stacey wrote:
Okay, we'll schedule the outage and rebuild for after the break.
On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
Sorry -- regarding your second bullet-point, I own one of these tickets, but it got pushed to not-the-top of the stack. I think implementing something that will have the effect Dan wants (but is not exactly the thing he suggests) shouldn't be difficult. - Tisha Craig Stacey wrote: | We've got a multi-pronged approach on this. | | * Dan's moving the authentications off the VM that is currently | serving authentication and back to the primary machine that was | serving authentications before. | | * We're trying to get ALCF to make some changes in the nagios-cmd | (IIRC) user that's spamming the logs and making it difficult for us to | troubleshoot the issue, but the tickets haven't gone anywhere. I've | asked Dan to talk to the admins in person to make this happen. | | If none of these are enlightening, we're going to (with ALCF) schedule | a brief downtime next week to follow the rebuild steps recommended by | CryptoCard in helping to solve this problem. We're also investigating | an alternate proxy configuration (or removing proxies) should the | rebuild not work. | | On Jan 7, 2011, at 2:35 PM, David E. Martin wrote: | |> Craig, |> Can you tell me the plan for digging into this? |> |> -David |> |> On 12/22/10 2:36 PM, Craig Stacey wrote: |>> Okay, we'll schedule the outage and rebuild for after the break. |>> |>> On Dec 22, 2010, at 2:27 PM, David E. Martin wrote: |>> |>>> In talking with Dan, it seems like the work-around is the best way |>>> to go. With Jini checking tickets and Dan available for backup, |>>> users will only be minimally affected by the problem. The 45 minute |>>> outage isn't a huge problem, but I'm not comfortable starting to |>>> poke deeply into Crypto-Server right before the break. |>>> |>>> -David |>>> |>>> On 12/22/10 11:41 AM, Dan Olson wrote: |>>>> Update: |>>>> |>>>> Cryptocard is sending me some troubleshooting steps to perform. |>>>> One of them is to restart replication using their method which |>>>> will require an outage of about 45 minutes. |>>>> |>>>> I'm implementing a workaround for the current situation as follows: |>>>> The crypto server will send mail to a mailing list consisting of |>>>> the crypto server operators when it disables any corrupt token. |>>>> The monitor script will start a validation process when a token is |>>>> detected as corrupt which will correct the checksum so the token |>>>> will be visible in the console, marked disabled. |>>>> When we receive the mails we can mark the token enabled, which |>>>> should allow the user to successfully logon without reinitializing |>>>> the token. |>>>> |>>>> The best window for the downtime before the break would be late |>>>> this evening, if we can't get the downtime this evening, I |>>>> recommend using the workaround until the new year. In its current |>>>> state our exposure to this issue appears to be limited to less |>>>> than 10 users per week. I will be checking the disabled token |>>>> emails at least daily over the break. Also, if anyone has any |>>>> issues over the break I will be local, and I can be reached |>>>> directly at 630-324-0000. |>>>> |>>>> ---- |>>>> Daniel Murphy-Olson |>>>> Systems Administrator |>>>> Mathematics& Computer Science Division |>>>> Argonne National Laboratory |>>>> 630-252-0055 |>>>> |>>>> ----- Original Message ----- |>>>> From: "Dan Olson"<[email protected]> |>>>> To: "core-admins"<[email protected]> |>>>> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. |>>>> Scott"<[email protected]> |>>>> Sent: Wednesday, December 22, 2010 9:59:36 AM |>>>> Subject: Crypto server status |>>>> |>>>> I've been on the phone working with cryptocard support all morning. |>>>> |>>>> The server has been detecting tokens as corrupt, it affected 4 |>>>> users yesterday, also per the logs it appears these four users |>>>> will have problems today. An overnight validation process |>>>> disabled them again. The rest of the users should be functional. |>>>> |>>>> The users are: |>>>> cdaley |>>>> gjordan |>>>> fischer |>>>> eholohan |>>>> |>>>> |>>>> I will send updates as soon as I have any. |>>>> |>>>> |>>>> ---- |>>>> Daniel Murphy-Olson |>>>> Systems Administrator |>>>> Mathematics& Computer Science Division |>>>> Argonne National Laboratory |>>>> 630-252-0055 |>>>> |>>>> |>>>> |>>> |>>> |> |
Craig, Thanks. Can you give me a timeline for this? -David On 1/7/11 2:45 PM, Craig Stacey wrote:
We've got a multi-pronged approach on this.
* Dan's moving the authentications off the VM that is currently serving authentication and back to the primary machine that was serving authentications before.
* We're trying to get ALCF to make some changes in the nagios-cmd (IIRC) user that's spamming the logs and making it difficult for us to troubleshoot the issue, but the tickets haven't gone anywhere. I've asked Dan to talk to the admins in person to make this happen.
If none of these are enlightening, we're going to (with ALCF) schedule a brief downtime next week to follow the rebuild steps recommended by CryptoCard in helping to solve this problem. We're also investigating an alternate proxy configuration (or removing proxies) should the rebuild not work.
On Jan 7, 2011, at 2:35 PM, David E. Martin wrote:
Craig, Can you tell me the plan for digging into this?
-David
On 12/22/10 2:36 PM, Craig Stacey wrote:
Okay, we'll schedule the outage and rebuild for after the break.
On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
I'll let Dan provide the finer details, but we want to schedule the outage window for this week. On Jan 10, 2011, at 3:53 PM, David E. Martin wrote:
Craig, Thanks. Can you give me a timeline for this?
-David
On 1/7/11 2:45 PM, Craig Stacey wrote:
We've got a multi-pronged approach on this.
* Dan's moving the authentications off the VM that is currently serving authentication and back to the primary machine that was serving authentications before.
* We're trying to get ALCF to make some changes in the nagios-cmd (IIRC) user that's spamming the logs and making it difficult for us to troubleshoot the issue, but the tickets haven't gone anywhere. I've asked Dan to talk to the admins in person to make this happen.
If none of these are enlightening, we're going to (with ALCF) schedule a brief downtime next week to follow the rebuild steps recommended by CryptoCard in helping to solve this problem. We're also investigating an alternate proxy configuration (or removing proxies) should the rebuild not work.
On Jan 7, 2011, at 2:35 PM, David E. Martin wrote:
Craig, Can you tell me the plan for digging into this?
-David
On 12/22/10 2:36 PM, Craig Stacey wrote:
Okay, we'll schedule the outage and rebuild for after the break.
On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
I've been taking packet captures over the last few days, and matching that data up to the corrupt tokens. I believe the problem lies in the speed the crypto server is able to service requests in conjunction with the settings in the ALCF pam radius and radius proxy configuration. The corrupt tokens occur when multiple radius auth requests come in from multiple NAS devices too quickly for the cryptocard server to answer them. So in effect we have multiple successful authentications with the same one-time password because there is more than one in flight transaction in memory. One of the ones I looked at had 6 authentication attempts from different ALCF sources within 10 seconds, 2 radius proxies and the logon server had all sent requests in to the radius server within that 10 second period. It took 11 or 12 seconds for the server to respond to the first request. This corrupted the token record. I had requested the ALCF radius config files earlier today, I didn't see any reply yet. I think fixing this may be as simple as tuning the timeouts in the radius config files. I would like to get the timeouts changed tomorrow so we can determine if we really need to take the servers down. To continue down cryptocard's troubleshooting path I will need a 2 hour window, with one hour of definite downtime, the other hour to back it out if there are issues. I'm proposing Thursday 1/13 at 8pm central for 2 hours. Alternately, I can do this over the weekend if it would cause less disruption. ---- Daniel Murphy-Olson Systems Administrator Mathematics & Computer Science Division Argonne National Laboratory 630-252-0055 ----- Original Message ----- From: "Craig Stacey" <[email protected]> To: "David E. Martin" <[email protected]> Cc: "Dan Olson" <[email protected]>, "Jini Ramprakash" <[email protected]>, "Avanthi Mantrala" <[email protected]>, "Robert R. Scott" <[email protected]>, "core-admins" <[email protected]>, "Tisha Stacey" <[email protected]>, "Michael E. Papka" <[email protected]> Sent: Monday, January 10, 2011 3:59:24 PM Subject: Re: Crypto server status I'll let Dan provide the finer details, but we want to schedule the outage window for this week. On Jan 10, 2011, at 3:53 PM, David E. Martin wrote:
Craig, Thanks. Can you give me a timeline for this?
-David
On 1/7/11 2:45 PM, Craig Stacey wrote:
We've got a multi-pronged approach on this.
* Dan's moving the authentications off the VM that is currently serving authentication and back to the primary machine that was serving authentications before.
* We're trying to get ALCF to make some changes in the nagios-cmd (IIRC) user that's spamming the logs and making it difficult for us to troubleshoot the issue, but the tickets haven't gone anywhere. I've asked Dan to talk to the admins in person to make this happen.
If none of these are enlightening, we're going to (with ALCF) schedule a brief downtime next week to follow the rebuild steps recommended by CryptoCard in helping to solve this problem. We're also investigating an alternate proxy configuration (or removing proxies) should the rebuild not work.
On Jan 7, 2011, at 2:35 PM, David E. Martin wrote:
Craig, Can you tell me the plan for digging into this?
-David
On 12/22/10 2:36 PM, Craig Stacey wrote:
Okay, we'll schedule the outage and rebuild for after the break.
On Dec 22, 2010, at 2:27 PM, David E. Martin wrote:
In talking with Dan, it seems like the work-around is the best way to go. With Jini checking tickets and Dan available for backup, users will only be minimally affected by the problem. The 45 minute outage isn't a huge problem, but I'm not comfortable starting to poke deeply into Crypto-Server right before the break.
-David
On 12/22/10 11:41 AM, Dan Olson wrote:
Update:
Cryptocard is sending me some troubleshooting steps to perform. One of them is to restart replication using their method which will require an outage of about 45 minutes.
I'm implementing a workaround for the current situation as follows: The crypto server will send mail to a mailing list consisting of the crypto server operators when it disables any corrupt token. The monitor script will start a validation process when a token is detected as corrupt which will correct the checksum so the token will be visible in the console, marked disabled. When we receive the mails we can mark the token enabled, which should allow the user to successfully logon without reinitializing the token.
The best window for the downtime before the break would be late this evening, if we can't get the downtime this evening, I recommend using the workaround until the new year. In its current state our exposure to this issue appears to be limited to less than 10 users per week. I will be checking the disabled token emails at least daily over the break. Also, if anyone has any issues over the break I will be local, and I can be reached directly at 630-324-0000.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
----- Original Message ----- From: "Dan Olson"<[email protected]> To: "core-admins"<[email protected]> Cc: "Jini Ramprakash"<[email protected]>, "Robert R. Scott"<[email protected]> Sent: Wednesday, December 22, 2010 9:59:36 AM Subject: Crypto server status
I've been on the phone working with cryptocard support all morning.
The server has been detecting tokens as corrupt, it affected 4 users yesterday, also per the logs it appears these four users will have problems today. An overnight validation process disabled them again. The rest of the users should be functional.
The users are: cdaley gjordan fischer eholohan
I will send updates as soon as I have any.
---- Daniel Murphy-Olson Systems Administrator Mathematics& Computer Science Division Argonne National Laboratory 630-252-0055
participants (5)
-
Craig Stacey -
Dan Olson -
Dan Olson -
David E. Martin -
Tisha Stacey