Freeradius Auth via LDAP against Active Directory Server 2003
I have been at this for awhile now, so I thought I would share a summary of what I have figured out so far for anyone else that decides to try this. 1 - Documentation for this particular configuration is either out of date / incomplete / both. There are no howtos that will get from start to end (if you do know of one or wrote one yourself please share - I will myself when I figure it all out). 2 - Most the trouble is due to the fact we are making a linux service talk to a windows service (AD LDAP). Freeradius talking to the linux passwd file is a breeze by comprassion. 3 - Windows 2003 LDAP implementation will not provide a password when a user/ service preforms a ldap search, the proper way If I understand correctly is to supply plain text username / password then freeradius preforms a bind with the provided credentials against your ADS server, success means the password was correct. 4 - Installing "Services For Unix" on 2003 will make AD LDAP provide a password hash attribute among other unix LDAP attributes. The user has have posix enabled. 5 - Anonymous searchs can be preformed on 2003 AD LDAP if you set dSHeuristics to 0000002 using adsiedit.msc. 6 - Microsofts LDAP is different to Novells (big surprise) and so unfortunately their documentation isnt to helpfull as a reference for people trying to use ADS in the same fashion.
Well I have another angle I will be attacking the problem from on the weekend. I will be installing and configuring OpenLDAP on my linux server making it replicate the ADS 2003 server then following the gentoo-wiki's Freeradius and OpenLDAP implementation howto. So the modified layout plan: client -> cisco wap -> linux + fr -> linux + openldap -> windows 2003 ADS At least this way I will have two LDAP implementations to test against, which ever works 1st becomes the default solution :). I Do understand that the novel eDirectory works very nicely (novells LDAP implementation) but due to pricing issues it will be left until the last option. I would like to say though Novell generally has excellent support. On 4/27/07, Jacob Jarick <mem.namefix@gmail.com> wrote:
I have been at this for awhile now, so I thought I would share a summary of what I have figured out so far for anyone else that decides to try this.
1 - Documentation for this particular configuration is either out of date / incomplete / both. There are no howtos that will get from start to end (if you do know of one or wrote one yourself please share - I will myself when I figure it all out).
2 - Most the trouble is due to the fact we are making a linux service talk to a windows service (AD LDAP). Freeradius talking to the linux passwd file is a breeze by comprassion.
3 - Windows 2003 LDAP implementation will not provide a password when a user/ service preforms a ldap search, the proper way If I understand correctly is to supply plain text username / password then freeradius preforms a bind with the provided credentials against your ADS server, success means the password was correct.
4 - Installing "Services For Unix" on 2003 will make AD LDAP provide a password hash attribute among other unix LDAP attributes. The user has have posix enabled.
5 - Anonymous searchs can be preformed on 2003 AD LDAP if you set dSHeuristics to 0000002 using adsiedit.msc.
6 - Microsofts LDAP is different to Novells (big surprise) and so unfortunately their documentation isnt to helpfull as a reference for people trying to use ADS in the same fashion.
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.
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
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
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
-----Original Message----- From: freeradius-users-bounces+frank.ranner=defence.gov.au@lists.fre eradius.org [mailto:freeradius-users-> bounces+frank.ranner=defence.gov.au@lists.freeradius.org] On Behalf Of Jacob Jarick Sent: Sunday, 29 April 2007 20:48 To: FreeRadius users mailing list Subject: Re: Freeradius Auth via LDAP against Active Directory Server 2003
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.
You should be able to set the base DN at the parent node, because the search is a subtree search. In my setup (openldap, not AD) I also use the base_filter directive in radiusd.conf to restrict the type of records to be searched. I use base_filter = "(objectclass=radiusprofile)" You should use base_filter = "(objectclass=user)" This goes into the ldap Section somewhere near the basedn line. Regards, Frank Ranner
Thanks frank, Regarding searching base dn from parent node (correct term I hope) I did try on the weekend but to no success but retrying today worked fine :) (quite possibly me doing more that one change at a time again). I also added the filter as per your suggestion. I appreciate the feedback as this has made things alot easier. On 4/30/07, Ranner, Frank MR <Frank.Ranner@defence.gov.au> wrote:
-----Original Message----- From: freeradius-users-bounces+frank.ranner=defence.gov.au@lists.fre eradius.org [mailto:freeradius-users-> bounces+frank.ranner=defence.gov.au@lists.freeradius.org] On Behalf Of Jacob Jarick Sent: Sunday, 29 April 2007 20:48 To: FreeRadius users mailing list Subject: Re: Freeradius Auth via LDAP against Active Directory Server 2003
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.
You should be able to set the base DN at the parent node, because the search is a subtree search. In my setup (openldap, not AD) I also use the base_filter directive in radiusd.conf to restrict the type of records to be searched. I use base_filter = "(objectclass=radiusprofile)" You should use base_filter = "(objectclass=user)" This goes into the ldap Section somewhere near the basedn line.
Regards, Frank Ranner
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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
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
Jacob, Could you please send the steps you followed to integrate ad with FR?. I am completely lost and confused with the information available on this . thanks, SB On 5/1/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
On Tue 01 May 2007, shrikant Bhat wrote:
Jacob, Could you please send the steps you followed to integrate ad with FR?. I am completely lost and confused with the information available on this .
Hi Jacob If you plan on documenting the steps that you took, can I respectfully request that you do so by either updating one of the existing HOWTOs, or creating a new one on our wiki at: http://wiki.freeradius.org/HOWTO Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
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
Ryan is correct, You can auth via ntlm then get groups via ldap. I would have pursued it further were I allowed to use samba. For People having trouble, well 3 things really helped me out alot once I got radtest working. 1 - If You must use LDAP for auth and no other (as my situation was) be aware that there really are only 2 methods available to you (that I know off) 1 FR -> LDAP or FR -> PAM -> LDAP. 2 - use secureW2 to enable win32 clients access to EAP-TTLS & PAP 3 - LDAP only supports PAP (when FR is concerned anyway I am unfamilar with microsofts radius server), if you try to use any other encryption / tunneling expect alot of grief (Im up 5 grey hairs). On 5/2/07, Ryan Kramer <rkramer@gmail.com> wrote:
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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sure, I have no probs doing it via the wiki. When I get a chance I will create. For me the biggest help was finding SecureW2, truly an excellent little app. On 5/2/07, Ryan Kramer <rkramer@gmail.com> wrote:
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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Ryan, I am now actually in the process of implementing your method. auth via ntlm retrevie attributes via ldap (group, dialup_access, etc) Can you suggest some reading or point me in the right direction. ATM I have ntlm and ldap configured and ntlm (hoping it might just work :P and for testing). If I comment out line 1566 it auths the machine but ignores the dialup attribute. All i need is a module to deny / override a users authentication if the dialup attribute isnt set. Thanks in advance. On 5/2/07, Ryan Kramer <rkramer@gmail.com> wrote:
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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Were you ever able to solve the issue of multipe OU's? I have about 100 OU's that have users under them, running without a specified OU doesn't work, and obviously once I drop into an OU it hits the users that live there, and no others. Ryan 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
On Tue, 2007-06-05 at 09:22 -0500, Ryan Kramer wrote:
Were you ever able to solve the issue of multipe OU's? I have about 100 OU's that have users under them, running without a specified OU
Why can't you specify a top-level OU and use subtree searches?
doesn't work, and obviously once I drop into an OU it hits the users that live there, and no others.
The "basedn" config item on the "ldap" module is dynamically expanded. If you can map a username to an OU, you could use a dynamic expansion there. But if you've got hundreds of OUs without a common ancestor and subtree search, I'd say you've designed your LDAP directory wrong.
Ryan
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
participants (6)
-
Jacob Jarick -
Peter Nixon -
Phil Mayers -
Ranner, Frank MR -
Ryan Kramer -
shrikant Bhat