...

My question is, how do I get an "Accept" from the request and is there a way around the basedn naming conventions that will alllow FreeRadius to work with Windowz?

The issue here isn't with basedn naming conventions. It's that you haven't set up FreeRADIUS to ask AD about authenticating the user.?

If the users log in with clear-text passwords, my suggestion is to set up rlm_smb, and point it to the domain controller. That will let FreeRADIUs use >AD for authentication.

Alan DeKok. I made some changes to the radiusd.conf to exclude what I thought was not needed and have much joy. The localhost client test is accepted.

With regard to the basedn naming convention I will explain my problem. Users created in AD with a first name and last name have a "cn=radius test" and the actual logon credentials are in "sAMAccountName=radtest". This presents a problem when a querry is passed. In the text below I have broken the "cn=" First and Last name entry by adding a backslash to the tail of the first name. The actual user account that was querried has a logon of "radtest" and not "radius test". Basically it is creating it's "distinguishedName" within the record, from one of two different places depending how the account was creted. Is there a way to work around this issue? Here is an "ldapsearch result" for 2 separate users The actual account logon credential is the "sAMAccountName" 111111111111111111111111111111111111111111111111111111111111111111111111 1111111111111111111111 # radius test, Users, xxxx1.xxxx1.edu dn: CN=radius test,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu objectClass: user cn: radius test sn: test givenName: radius distinguishedName: CN=radius test,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu displayName: radius test name: radius test logonCount: 0 sAMAccountName: radtest sAMAccountType: 805306368 userPrincipalName: radtest@xxxx1.xxxx2.edu objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=xxxx1,DC=xxxx2,DC=edu 222222222222222222222222222222222222222222222222222222222222222222222222 22222222222222222222222 # testing, Users, xxxx1.xxxx2.edu dn: CN=testing,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu objectClass: user cn: testing givenName: testing distinguishedName: CN=testing,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu displayName: testing name: testing logonCount: 0 sAMAccountName: testing sAMAccountType: 805306368 userPrincipalName: testing@xxxx1.xxxx2.edu objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=xxxx1,DC=xxxx2,DC=edu ************************************************************************ *************************************** Here is the output from the localhost requesting "radtest on logon radtest" and the debug from the FreeRADIUS: [john@magellan ~]$ radtest radius\ test Passw0rd localhost 0 testing123 Sending Access-Request of id 62 to 10.1.1.27:1812 User-Name = "radius test" User-Password = "Passw0rd" NAS-IP-Address = localhost.xxxx1.xxxx2.edu NAS-Port = 0 rad_recv: Access-Accept packet from host 10.1.1.27:1812, id=62, length=20 And the debug.... Waking up in 31 seconds... Thread 5 got semaphore Thread 5 handling request 34, (7 handled so far) User-Name = "radius test" User-Password = "Passw0rd" NAS-IP-Address = 255.255.255.255 NAS-Port = 0 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 34 modcall[authorize]: module "preprocess" returns ok for request 34 modcall[authorize]: module "mschap" returns noop for request 34 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 34 rlm_ldap: - authorize rlm_ldap: performing user authorization for radius test radius_xlat: '(cn=radius test)' radius_xlat: 'ou=Users,dc=xxxx1,dc=xxxx2,dc=EDU' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=Users,dc=xxxx1,dc=xxxx2,dc=EDU, with filter (cn=radius test) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user radius test authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 34 modcall: group authorize returns ok for request 34 rad_check_password: Found Auth-Type LDAP auth: type "LDAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 34 rlm_ldap: - authenticate rlm_ldap: login attempt by "radius test" with password "Passw0rd" rlm_ldap: user DN: CN=radius test,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu rlm_ldap: (re)connect to xxxx1.xxxx2.EDU:389, authentication 1 rlm_ldap: bind as CN=radius test,OU=Users,DC=xxxx1,DC=xxxx2,DC=edu/Passw0rd to xxxx1.xxxx2.EDU:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: user radius test authenticated succesfully modcall[authenticate]: module "ldap" returns ok for request 34 modcall: group Auth-Type returns ok for request 34 Sending Access-Accept of id 62 to 10.1.1.27:32858 Finished request 34 Going to the next request Thread 5 waiting to be assigned a request --- Walking the entire request list --- Cleaning up request 34 ID 62 with timestamp 43c3bea7 Nothing to do. Sleeping until we see a request.