[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freeradius-users
Subject:    Re: AD-integration working well - questions about risk/exposure and related mechanisms
From:       Alan DeKok <aland () deployingradius ! com>
Date:       2023-01-16 19:50:12
Message-ID: 1A5FD12B-29F0-42B3-A559-7D5BF113F65D () deployingradius ! com
[Download RAW message or body]

On Jan 16, 2023, at 2:32 PM, Dag B <dag@bakke.com> wrote:
> So, after some fiddling, I can now authenticate users of our network gear (network \
> admins) with AD, via freeradius. Thank you to any and all who have made that \
> possible. It is truly appreciated.

  Good to hear.

> Arriving here, I just wanted to ask if there is any document discussing any \
> additional risk or exposure for the AD-accounts by doing this.

  Many sites are simply terrible.  People read confusing vendor documentation, leap \
to conclusions, and write "helpful" articles full of misleading nonsense.  That being \
said, the best summary is here:

	https://networkradius.com/articles/2022/10/25/is-ntlm-secure.html

  But... there's no reason to panic over "ntlm_auth is insecure".  Do you let random \
people snoop the network traffic between RADIUS and AD?  No?  Then ntlm_auth is fine.

  If you do let random people snoop traffic on the management network, then the \
insecurity of ntlm_auth is the least of your problems.

> Note: I am not trying to imply there is one, nor am I trying to sell five feathers \
> as whole chicken in a bag or however that analogy goes. I am merely acknowledging \
> my relative ignorance w.r.t. how AD and RADIUS works and what security mechanisms \
> it has in place for preventing abuse. 
> From the top of my head:
> 
> - Can someone use freeradius for unlimited tries at guessing an AD password?

  Pretty much, though you can limit that manually by tracking failed authentications.

  However, the usefulness of such an attack is severely limited by the performance \
limitations of AD and WiFi authentication.  We've done performance tests showing AD \
maxes out at a few hundred auths/s.  In order to do any real dictionary attack, an \
attacker would need to do tens of thousands a second.

  So good news, AD is too slow to be attacked in any reasonable manner.

> - If the radius secret becomes known to a bad actor, could they set up a 'farm' of \
> radius clients in the defined client address spaces to bypass rate limits?

  See above.  Sending more packets doesn't make AD faster.

> - And likewise, could they instrument their radius client to reveal more \
> information than we intend to?

  No.

> - Is there a better way to define clients than defining static hosts or networks in \
> clients.conf? (We have an IPAM with an API. Could we employ this to only permit \
> radius requests from known (expected) radius clients?)

  Yes.  See sites-available/dynamic-clients

> And I am certain there are more questions I should be asking. Conscious \
> Incompetence and all that jazz....

  Asking questions is good.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


[prev in list] [next in list] [prev in thread] [next in thread]