Advice on simple password implementation?

[Ted Hyde (RSI)]

Greets! This a little FR-related, and a bit more system advice-related. 
The end result is possibly to implement on FR, of course.

I typically implement FR in an EAP-TLS (note just TLS, not tunneled-TLS) 
scenario where client certificates are manually installed on the 
supplicants (such as tablets) because I have the luxury of controlling 
that. It works fine and although it may not be a perfect practice if 
revoking is necessary, it makes the deployment and control for field 
personnel consistent and dependable. It keeps by blood pressure low, 
which is amazing for IT components.

I have a different situation where the installation has a lot of 
transient supplicants (guest staff coming and going) and the connection 
path was simply to go WPA and share the key (via secure post-it, of 
course) with that guest staff. I don't love this setup, but it does 
work. If the key becomes compromised, we have to go in and change in 
each NAS (the access points / NAS are Cisco autonomous AP's - no WAP 
since they are spread out further and across different logical nets). I 
have a little automatic script that can do this, but it ends up giving 
the script administrative access to the NAS's so it's a possible 
security concern.

To make matters worse, I will be leaving the setup after it is done, and 
I have a concern that certificates may expire after my departure causing 
a traditional EAP-TTLS option to fail, else that would also be an option.

Is there a practical configuration to set up the AP's (not sure if 
EAP-TTLS can be re-written to ignore certificates, just use a 
username/password?) to create a system that would generate a [daily] 
random password that could be given to a guest staff, for which they can 
quickly enter and gain access, but that credential changes on a 
recurring basis? I can write the credential assignment portion 
separately, and store it in db/file for FR, but it's the config of FR 
that I don't know about.

I recall having visited some other vendor sites that had a captive 
portal that did a similar thing, but I think they did that at the L3 
level, not at the initial AAA level on the NAS. (As in the wireless was 
completely open, and they controlled routing, not connection). Since I 
would have a working FR setup, I would prefer to not need to have 
another application layer to handle just one client purpose.

I'm sure this will bring on lots of "you're doing it so wrong" replies, 
but go ahead anyway.

Many thanks,

Ted.