Advice on simple password implementation?
Ted Hyde (RSI)
thyde at rndstudio.com
Wed Aug 14 14:18:49 CEST 2019
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
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.
More information about the Freeradius-Users