Log InThe root cause for both messages is the same, and is unambiguous: The shared secret on the RADIUS server and the NAS are not the same.
However, there can be some confusion because, depending on what information RADIUS receives in the packet header, you will see either the error message or the warning.
There are also several scenarios where system administrators might think that the shared secret is the same on the RADIUS server and the NAS, when in fact, they are not.
This article will explain why those messages turn up in slightly different contexts, and how you can fix the problem.
The bottom line
When there is a mismatch between the shared secret on the RADIUS server and the NAS, RADIUS will log one of the following messages.
Received packet from <IP address> with invalid Message-Authenticator! (Shared secret is incorrect.)
or
WARNING: Unprintable characters in the password. Double-check the shared secret on the server and the NAS!
The difference in messages comes down to whether or not the packet received by FreeRADIUS was signed. However, the root cause is exactly the same. The shared secret on RADIUS server and the NAS are different.
Let’s back up a bit and take a look at what happens when the server receives a packet from the NAS. Before doing anything else, the server needs to verify that this packet came from a trusted source, and not from an attacker, such as a rogue access point. The RADIUS protocol uses the shared secret to verify that whoever sent the packet is trusted. After all, we do not want untrusted people checking if users passwords are correct! Allowing packets only from trusted sources means that your passwords are safe from people trying to brute-force guess them.
Invalid Message-Authenticator! (Shared secret is incorrect.)
The Shared secret is incorrect error appears when the packet signature is wrong. When the packet header contains a signature, this check is very straightforward. The packet signature is checked using the shared secret. If the signature calculated by FreeRADIUS is the same as the signature in the packet, then the packet came from a trusted source. If the signatures are not the same, then the packet is dropped, and an error message is logged.
WARNING: Unprintable characters in password
In some cases, Access-Request packets do not contain a signature. When that happens, FreeRADIUS can check that the packet is from a known source by looking up the source IP address. However, FreeRADIUS cannot verify if the packet is from a trusted source. To make an educated guess about the trustworthiness of the source, when the packet contains a password, FreeRADIUS will decrypt the password using the shared secret.
If the shared secret between the NAS and the RADIUS server does not match, the decrypted password will almost always end up as random data. When printed, this password looks like random characters, including characters which the user cannot type on the keyboard! Such a password would be an extremely unusual (if not impossible) password for a user. When FreeRADIUS sees that the password contains unprintable characters, it logs a warning message, along with a suggestion that the underlying cause is a shared secret mismatch.
After flagging the weird password issue, FreeRADIUS then proceeds with the authentication process and checks the submitted password against the database. Naturally, in the vast majority of cases, this authentication step will fail because unprintable characters in passwords are exceedingly rare.
In this case, the reply packet will almost always be Access-Reject. This reply packet is also signed with the shared secret. Since the NAS and server have different shared secrets, the NAS will see that the packet signature is “wrong” for the shared secret it has, and will ignore the Access-Reject. The NAS will never receive a packet it trusts, so it will eventually give up, and drop the users connection.
The purpose of this warning message is to help the system administrator understand the root cause of authentication failures. Without the initial sanity check based on the shared secret, a failed authentication could easily be interpreted as a mismatch between the submitted password and the stored password. By flagging the password as highly unusual, FreeRADIUS is telling the administrator that the most likely source of the problem is a mismatch with the shared secret, and not that the users password is wrong.
But my shared secret IS the same! What else could be going on?
When we see questions about these messages on the FreeRADIUS mailing list or StackOverflow, they tend to be some variation of “I DID double check the shared secret on RADIUS and the NAS, and it IS the same in both places. The problem must be something other than what the error message is telling me”.
It’s understandable for people to be frustrated with this because there are a few reasons why the shared secret might appear to be the same on RADIUS and the NAS, but it isn’t. Let’s start with the straightforward ones.
1) The shared secret contains special characters. Sometimes special characters in different languages are represented differently on different systems, which leads to a mismatch between what is stored on the RADIUS server vs. the NAS
To rule out this issue, temporarily change the shared secret to something very simple like “hello” and see if that resolves the problem. Try to limit the shared secret to using a small set of characters (usually US-ASCII), but make it secure by using a long (32 character) string.
2) There are extra white spaces in the shared secret. Sometimes a shared secret might contain an extra space or tab in one place, and not the other. This can often occur as a result of copying and pasting, especially if the shared secret is long and complex and uses special characters. It can be easy to inadvertently pick up an extra character, which will make the shared secret different from the original.
To rule out this issue, temporarily change the shared secret to something simple as suggested in step one, but be careful to not copy and paste, but (carefully) type in.
3) FreeRADIUS is not picking up the shared secret from the place you think it is. FreeRADIUS generally looks for the shared secret in the /etc/raddb/clients.conf file. If that is not where you are changing the shared secret, RADIUS won’t see your changes and won’t behave the way you expect.
To rule out this issue, double check the clients.conf file to make sure it has the entries you expect. Again, it’s best to test with very simple passwords, without copying and pasting. Read the debug output (radiusd -X) to see which file is being read by the server, and what the shared secret is for each client.
More advanced troubleshooting
The vast majority of the time, the shared secret mismatch can be resolved with these straightforward checks. If you are still seeing the same error messages after doing those checks, you’ll need to dig a little bit deeper.
1) Verify that the packets are sent with the shared secret you think it was signed with. You will need to use a tool like radsniff (included in FreeRADIUS) or tcpdump to capture the packets coming from the problematic client. Tcpdump will provide a PCAP file which contains detailed packet information which can then be inspected with a tool like wireshark.
2) Verify that the RADIUS server is using the client definition you expect.
This can sometimes be confusing if your configuration uses different subnet definitions. When checking the shared secret (and other fields) RADIUS will use the most specific client definition it has available. Check your clients.conf file for multiple client definitions within a subnet. If you define different shared secrets for different clients, try setting them all to the same thing.
More information on troubleshooting is available on the FreeRADIUS Wiki.
Need more help?
Network RADIUS is the team behind FreeRADIUS. We develop and maintain the open source product, write the documentation, moderate the FreeRADIUS mailing list, and answer questions in public forums. Our team knows FreeRADIUS inside and out.
In addition to supporting the free, open source community, we specialize in helping clients configure, deploy, and maintain complex RADIUS infrastructure. If you’d like help from the people that wrote FreeRADIUS, contact us for a customized quote.
