You can take care of #1 by still doing LDAP to AD for the groups, but using ntlm for the password authentication. This seems counterproductive, unless you are using a backside encryption where you need to do it that way, which is what I ended up having to do. On 4/30/07, Jacob Jarick <mem.namefix@gmail.com> wrote:
Thanks for the Tip ryan but I have been down that road and 2 reasons stopped me:
1 - no way of retrieving ldap groups 2 - Been requested not to have samba on the machine.
ntlm_auth was very straight forward for me because it supports all the encryption methods.
On 5/1/07, Ryan Kramer <rkramer@gmail.com> wrote:
depending on the wifi auth method, you may want to also investigate a NTLM_AUTH method instead of straight ldap. This requires the freeradius machine to be a member of the domain, but once you do that it works great.
On 4/29/07, Jacob Jarick <mem.namefix@gmail.com> wrote:
OK tried with 1.1.4 and yerp works great.
radiusd -X output: http://pastebin.ca/464153 radiusd.conf: http://pastebin.ca/464156
I also realised a mistake I have been making, see I want to search the whole active directory, hence I kept setting my basedn without an ou. After seeing your excellent example and auth'ing had failed I stuck in an OU and tried a user from the OU and worked fine.
So my questions is this, to auth people from multiple OU's do I create a new ldap module for each OU or is their a simpler way.
Thanks Very much for your help Phil, its been a very productive weekend thanks to the info you provided.
My challenge for monday will be setting up the cisco and wireless clients now :)
On 4/29/07, Jacob Jarick <mem.namefix@gmail.com > wrote:
radiusd.conf: http://pastebin.ca/464133 radius -X ouput: http://pastebin.ca/464138
Tried with 1.1.6 and fails with this error:
rlm_ldap: reading ldap<->radius mappings from file /etc/raddb/ldap.attrmap rlm_ldap: Opening file /etc/raddb/ldap.attrmap failed rlm_ldap: Reading dictionary mappings from file /etc/raddb/ldap.attrmap failed radiusd.conf[540]: ldap: Module instantiation failed. radiusd.conf[586] Unknown module "ldap". radiusd.conf[586] Failed to parse "ldap" entry. ----------------------------- /etc/raddb/ldap.attrmap does exist as provided by the rpm.
[root@localhost src]# ls -l /etc/raddb/ldap.attrmap -rw-r----- 1 root root 2424 Apr 19 16:32 /etc/raddb/ldap.attrmap
I assume the permissions are correct, as it was installed by rpm. Im building the 1.1.4 rpm now, will report back once done.
On 4/29/07, Jacob Jarick <mem.namefix@gmail.com> wrote:
Thanks for the very detailed instructions.
I will attempt this shortly (bought rad & ad servers home for weekend study).
Quite possible the biggest learning curve for me is the ldap fields but I am finally starting to get familar with them.
Cheers again, will post back once Ive run the radtest.
On 4/28/07, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I haven't been following your (quite extensive) queries, so apologies if I've missed something fundamental.
I honestly don't know why this is proving so difficult. I've just tested this against our own 2k3 AD service, and although I'm pretty familiar with FR it took under 5 minutes. Try following the instructions below. These were tested with FreeRadius 1.1.4
1. First, create or locate an existing account which FreeRadius can bind and do it's searches as. Record the following variables:
SEARCHDN=<the DN of the account> SEARCHPW=<the password> BASEDN=<the DN below which all your accounts live in AD> ADHOST=<hostname of the AD controller you'll search against>
For example, these might be:
SEARCHDN=CN=freeradius,OU=Users,OU=My Site,DC=mysite,DC=com SEARCHPW=blahblah BASEDN=OU=My Site,DC=mysite,DC=com
2. Next, take the default "radiusd.conf"
3. Find the start of the modules section:
modules { ...
Delete this line and all the following lines
4. Insert the following config:
modules { ldap { server = "$ADHOST" identity = "$SEARCHDN" password = "$SEARCHPW"
basedn = "$BASEDN" filter = "(sAMAccountName=%{Stripped-User-Name:-%{User-Name}})"
dictionary_mapping = ${raddbdir}/ldap.attrmap
ldap_connections_number = 5 timeout = 4 timelimit = 3 net_timeout = 1 }
preprocess { huntgroups = ${confdir}/huntgroups hints = ${confdir}/hints
with_ascend_hack = no ascend_channels_per_line = 23
with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no }
detail { detailfile = ${radacctdir}/%{Client-IP-Address}/detail-%Y%m%d detailperm = 0644 }
}
instantiate { }
authorize { preprocess
ldap }
authenticate { Auth-Type LDAP { ldap } }
preacct { preprocess }
accounting { detail }
session { }
post-auth { }
pre-proxy { }
post-proxy { }
5. Start the server with -X
6. Run "radtest" to send a checking PAP request
It should work.
The above config is the ABSOLUTE BARE MINIMUM server config which will check PAP requests ONLY against an AD LDAP server. I do NOT recommend you go into service with this config. Try to look at it, understand how it's doing what it's doing, *then* start again with the default FreeRadius config and make the absolute minimum changes to get back to that point. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html