This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Yesterday I have hit one of these bugs (I guess CSCvf62998) on our deployment (ISE 188.8.131.520, Patch 6).
The workaroud stated in the BugDetails doesn't do it either:
Change the timezone of the computer accessing the sponsor portal to the timezone of the to be created guest's timezone.
Beentheredonethat !! No effect !!!
These timezone problems seem to be in every release ever published !!!! Can somebody tell me, if this bug has been taken care of in ISE 2.3 ?? Or if there is a patch on the way for 2.2 to fix this ??
what exactly is the problem you're having? I can see the bug ID, but when and how does this manifest itself? Do you have more than one timezone in your deployments?
I raised a TAC case recently where I argued that the ISE reports incorrect Failure Reason when guest enters incorrect password (feature request CSCvi04031). So, I only operate in one timezone, and all my accounts are created for that timezone and are immediately active as soon as they are created.
In the case where a guest has never logged into the portal before, AND, if he types the password incorrectly, then the Authentication Failure Reason is "Account is not yet active. Cisco argue that this is true, because the user has never logged in, hence the Status is not "Active". But this is nonsense because Cisco have overloaded the term "Active" to mean two different things.
Account active should mean that the guest is able to log in at the correct timezone.
TAC reluctantly filed an enhancement request and we'll see if that ever see the light of day. I think if this is not resolved then ISE operations people will be mislead and waste time wondering why users can't log in - potentially telling them nonsense, like, "your account is not yet active"
>>> what exactly is the problem you're having? I can see the bug ID, but when and how does this
>>> manifest itself? Do you have more than one timezone in your deployments?
The exact problem is this:
Any guest-userid, that is created by a sponsor using the sponsor-portal, throws "Account not valid yet" on ISE logging when used to log into the guest-portal. Even if you set the "begin" date and time to your actual current time.
I did this last friday:
- Created a new test-guestid (immediately valid)
- Tried to use it (like 5 minutes later), got rejected, ISE log shows "not valid yet"
- Went home, spent a nice ISE-free weekend :-)
- Came back on monday, used the same user-id as on friday, worked like a charm this time !!!
All ISEs in our deployment use NTP and have Europe/Berlin set as timezone. Same date, time and timezone as on the client from which the sponsor connects and on any guest-user system ...
Within the guest/sponsor configuration on ISE there is only one location with one ssid configured and the timezone is also set to Europe/Berlin. The default location and timezone (San Jose/America/Los Angeles) is still in the config also.
ISE version is 2.2, patch6.
I feel your pain! I smell a bug - that familiar smell :-) But all of this stuff is a bit of a cat and mouse game to piece the logic together. Having said all this, I found ISE 2.2 to be the worst release ever and I moved off onto 2.3 - seems a bit better. Patched to latest patch 2 this week and so far so good.
And at first glance it should just work if you have configured everything correctly. Before you open a TAC case (and get told the usual catchphrase in a nonchalant manner "... ah yes, you are 'hitting' bug XYZ ...") just check a few more things. I am sure you have already done this.
And then the Sponsor who created the account has to be in a Sponsor Group that matches the timezone. e.g. in my case I only have Queensland as my one and only location for all Sponsor Groups
I have my timezones configured thusly
Changing settings of guest type from ''From sponsor specified date' to ''From First login'' it really helped me to fix issue in our environment.
we are running 184.108.40.2068 on ISE and facing issue with timezone mismatch for more details you can refer ( https://supportforums.cisco.com/t5/other-wireless-mobility-subjects/ise-2-3-sponsor-created-account-start-time-difference/m-p/3376522#M83961)
I still have TAC case open and will keep chasing cisco to fix it with setting of ''From sponsor specified date''
Thanks once again
Also check your guest time window inside guest types, i ran into an issue where testing after 7pm was kicking me out, but the error was the same as you all were facing.
We had this same issue. We too changed time zones and that did not help. Finally, we did find a work around..
This is a configuration in individual guest-type.
Maximum Access time:
From first login (Check this option) .... The account will become active only when the user logs in.
From sponsor specified date
Downside of this is:
Account duration will remain blank when you notify a guest his credentials through email or print it.
We did this to every guest-type of ours and it solved the problem.
P.S: Please rate helpful posts. Thank you!