pap always returns noop for windows dialup authentication
hi all - i've recently tried upgrading from v1 to v2. on a centos 6.4 box w/ all latest updates, i installed freeradius v2, added one username and password to /etc/raddb/users: test Cleartext-Password := "testing" and the radtest command-line authentication works. i then added one client for our blade server to /etc/raddb/clients.conf: client x.x.x.x { secret = xxxxx shortname = 3coms } substituting the correct ip and secret for the x's. testing from my linux box w/ a modem, authentication works. output from radiusd -X shows all is well, my linux box receives an ip address and dns servers. relavant -X debug output shows: ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "testing" [pap] Using clear text password "testing" [pap] User authenticated successfully ++[pap] returns ok however, when trying to authenticate from a windows box, authentication fails. every time. i've tried it from a windows xp machine and 2 windows 7 machines. the debug output always says: [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject i've been over and over everything a dozen times, have tried changing the windows dialup security settings to use pap only, and also have tried adding the following line to the users file: Auth-Type = PAP even though everything i've read said not to do that. still doesn't work. the only changes i've made to the default installation are to the users and clients.conf files. i have spent hours searching the internet for a similar problem/solution and come up empty. windows boxes will not authenticate, pap always returns noop, and the user is rejected. am i doing something glaringly wrong, or just going plain crazy? regards, paul
On 23/09/13 17:33, paul trader wrote:
am i doing something glaringly wrong, or just going plain crazy?
It's difficult to say, because the debug you sent has all the useful bits trimmed out - like the original packet, and the full module processing chain. Send a full debug, and odds are someone will spot the issue. Most likely is that the Windows machine is sending a different format of username e.g. DOMAIN\user, so whatever database you're doing a lookup for the password or hash - SQL, LDAP, files - isn't matching. But that's a guess - post the full debug.
eOn Mon, 23 Sep 2013 at 17:52, Phil Mayers opined: PM:It's difficult to say, because the debug you sent has all the useful PM:bits trimmed out - like the original packet, and the full module PM:processing chain. hi phil - ok, here's the full debug for a successful request: rad_recv: Access-Request packet from host x.x.x.x port 1812, id=37, length=133 User-Name = "test" User-Password = "testing" User-Password = "testing" NAS-IP-Address = x.x.x.x NAS-Identifier = "x.x.x.x" NAS-Port = 2561 Acct-Session-Id = "167773864" Service-Type = Login-User Calling-Station-Id = "xxxxxxxxxx" Called-Station-Id = "xxxxxxx" NAS-Port-Type = Async # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry test at line 1 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop ++[pap] returns updated Found Auth-Type = PAP # Executing group from file /etc/raddb/sites-enabled/default +- entering group PAP {...} [pap] login attempt with password "testing" [pap] Using clear text password "testing" [pap] User authenticated successfully ++[pap] returns ok # Executing section post-auth from file /etc/raddb/sites-enabled/default +- entering group post-auth {...} ++[exec] returns noop Sending Access-Accept of id 37 to x.x.x.x port 1812 Finished request 2. Going to the next request Waking up in 4.9 seconds. Cleaning up request 2 ID 37 with timestamp +676 and here's the full output of a failed request: Ready to process requests. rad_recv: Access-Request packet from host x.x.x.x port 1812, id=35, length=121 User-Name = "test" User-Password = "testing" NAS-IP-Address = x.x.x.x NAS-Identifier = "x.x.x.x" NAS-Port = 2561 Acct-Session-Id = "167773862" Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = "xxxxxxxxxx" Called-Station-Id = "xxxxxxx" NAS-Port-Type = Async # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 35 to 64.214.93.3 port 1812 Waking up in 4.9 seconds. Cleaning up request 0 ID 35 with timestamp +361 from what i can see, the successful request finds the user's entry in the user table, but the failed request doesn't (and uses DEFAULT instead). but the usernames passed in seem to be the same. i don't know, we've used freeradius for years and this is the 1st time i'm having a problem. weird. regards, paul
On 09/23/2013 01:19 PM, paul trader wrote:
eOn Mon, 23 Sep 2013 at 17:52, Phil Mayers opined:
PM:It's difficult to say, because the debug you sent has all the useful PM:bits trimmed out - like the original packet, and the full module PM:processing chain.
You still haven't sent the full debug.
hi phil - ok, here's the full debug for a successful request:
[files] users: Matched entry test at line 1
and here's the full output of a failed request:
[files] users: Matched entry DEFAULT at line 172
So there's your answer, in the successful case it matched the entry for text on line 1, on the failed case it didn't match. So either you're not using the same users file (a full debug would have told us that) or you've got some criteria set for the test entry which isn't being matched. Also, you said you were moving from v1 to v2, you can't just copy v1 configs over, they're different, hope you weren't doing that. -- John
On Mon, 23 Sep 2013 at 13:31, John Dennis opined: JD:You still haven't sent the full debug. hi john - thanks for your reply. i sent the output from running radiusd -X, are you saying i need to run -Xxx and send that instead? or are you looking for the startup output as well? i only included the output for the particular requests. JD:Also, you said you were moving from v1 to v2, you can't just copy v1 JD:configs over, they're different, hope you weren't doing that. i used a default v2 install and only changed the users and clients.conf files. everything else was left alone. regards, paul
On 09/23/2013 02:07 PM, paul trader wrote:
On Mon, 23 Sep 2013 at 13:31, John Dennis opined:
JD:You still haven't sent the full debug.
hi john - thanks for your reply. i sent the output from running radiusd -X, are you saying i need to run -Xxx and send that instead?
No. It means all the output from radiusd -X. Yes, that might seem like a lot but it contains useful information. But before you do send it to this list see below.
or are you looking for the startup output as well? i only included the output for the particular requests.
That's not the full debug is it? :-)
JD:Also, you said you were moving from v1 to v2, you can't just copy v1 JD:configs over, they're different, hope you weren't doing that.
i used a default v2 install and only changed the users and clients.conf files. everything else was left alone.
You have all the information you need to debug your problem. It does require reading the debug output carefully. But you should really try to do that yourself first. As a said earlier, verify you're reading the exact same users file in both cases (the debug output will tell you what files are being read), If they are then look at your users file and determine why the user name is not matching, there is nothing magic about it, it should be straight forward. Still stumped? Then come back to the list for help. -- John
On Mon, 23 Sep 2013 at 14:42, John Dennis opined: JD:You have all the information you need to debug your problem. It does JD:require reading the debug output carefully. But you should really try JD:to do that yourself first. As a said earlier, verify you're reading the JD:exact same users file in both cases (the debug output will tell you JD:what files are being read), If they are then look at your users file JD:and determine why the user name is not matching, there is nothing magic JD:about it, it should be straight forward. Still stumped? Then come back JD:to the list for help. hi john - thanks for the help. however, i've read the debug output about 50 thousand times and am just not seeing what is causing the problem, other than it not finding the username in the /etc/raddb/users file when trying to authenticate from a windows box. i mean, the debug output from the authentication request shows the username to be "test" and there's clearly a user named "test" in the users file. every place in the debug output where it lists the username it's "test". there doesn't seem to be any domain prepended to it. when starting the server, the debug output shows the file 'modules/files' is being instantiated: Module: Instantiating module "files" from file /etc/raddb/modules/files files { usersfile = "/etc/raddb/users" acctusersfile = "/etc/raddb/acct_users" preproxy_usersfile = "/etc/raddb/preproxy_users" compat = "no" } and the user/password is in the /etc/raddb/users file. if it weren't then the linux authentication requests wouldn't be working either, right? i'm not trying anything complicated. this setup is not using ldap, active directory, and it's not talking to a database. it's just supposed to be reading a plain-text username and password from the users file. here's the full debug output: [root@ikano raddb]# radiusd -X FreeRADIUS Version 2.1.12, for host x86_64-redhat-linux-gnu, built on Oct 3 2012 at 01:22:51 Copyright (C) 1999-2009 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Starting - reading configuration files ... including configuration file /etc/raddb/radiusd.conf including configuration file /etc/raddb/proxy.conf including configuration file /etc/raddb/clients.conf including configuration file /etc/raddb/clients.conf.swave including files in directory /etc/raddb/modules/ including configuration file /etc/raddb/modules/mac2vlan including configuration file /etc/raddb/modules/expiration including configuration file /etc/raddb/modules/radutmp including configuration file /etc/raddb/modules/replicate including configuration file /etc/raddb/modules/rediswho including configuration file /etc/raddb/modules/chap including configuration file /etc/raddb/modules/mschap including configuration file /etc/raddb/modules/counter including configuration file /etc/raddb/modules/etc_group including configuration file /etc/raddb/modules/logintime including configuration file /etc/raddb/modules/digest including configuration file /etc/raddb/modules/preprocess including configuration file /etc/raddb/modules/exec including configuration file /etc/raddb/modules/checkval including configuration file /etc/raddb/modules/wimax including configuration file /etc/raddb/modules/realm including configuration file /etc/raddb/modules/expr including configuration file /etc/raddb/modules/sql_log including configuration file /etc/raddb/modules/opendirectory including configuration file /etc/raddb/modules/inner-eap including configuration file /etc/raddb/modules/sqlcounter_expire_on_login including configuration file /etc/raddb/modules/echo including configuration file /etc/raddb/modules/mac2ip including configuration file /etc/raddb/modules/attr_rewrite including configuration file /etc/raddb/modules/smbpasswd including configuration file /etc/raddb/modules/pam including configuration file /etc/raddb/modules/smsotp including configuration file /etc/raddb/modules/ippool including configuration file /etc/raddb/modules/passwd including configuration file /etc/raddb/modules/detail.log including configuration file /etc/raddb/modules/dynamic_clients including configuration file /etc/raddb/modules/always including configuration file /etc/raddb/modules/detail including configuration file /etc/raddb/modules/ntlm_auth including configuration file /etc/raddb/modules/linelog including configuration file /etc/raddb/modules/detail.example.com including configuration file /etc/raddb/modules/attr_filter including configuration file /etc/raddb/modules/acct_unique including configuration file /etc/raddb/modules/soh including configuration file /etc/raddb/modules/unix including configuration file /etc/raddb/modules/cui including configuration file /etc/raddb/modules/files including configuration file /etc/raddb/modules/otp including configuration file /etc/raddb/modules/redis including configuration file /etc/raddb/modules/pap including configuration file /etc/raddb/modules/sradutmp including configuration file /etc/raddb/modules/perl including configuration file /etc/raddb/modules/policy including configuration file /etc/raddb/eap.conf including configuration file /etc/raddb/policy.conf including files in directory /etc/raddb/sites-enabled/ including configuration file /etc/raddb/sites-enabled/default including configuration file /etc/raddb/sites-enabled/inner-tunnel including configuration file /etc/raddb/sites-enabled/control-socket main { user = "radiusd" group = "radiusd" allow_core_dumps = no } including dictionary file /etc/raddb/dictionary main { name = "radiusd" prefix = "/usr" localstatedir = "/var" sbindir = "/usr/sbin" logdir = "/var/log/radius" run_dir = "/var/run/radiusd" libdir = "/usr/lib64/freeradius" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = yes log { stripped_names = no auth = no auth_badpass = no auth_goodpass = no } security { max_attributes = 200 reject_delay = 1 status_server = yes } } radiusd: #### Loading Realms and Home Servers #### proxy server { retry_delay = 5 retry_count = 3 default_fallback = no dead_time = 120 wake_all_if_all_dead = no } home_server localhost { ipaddr = 127.0.0.1 port = 1812 type = "auth" secret = "testing123" response_window = 20 max_outstanding = 65536 require_message_authenticator = yes zombie_period = 40 status_check = "status-server" ping_interval = 30 check_interval = 30 num_answers_to_alive = 3 num_pings_to_alive = 3 revive_interval = 120 status_check_timeout = 4 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server_pool my_auth_failover { type = fail-over home_server = localhost } realm example.com { auth_pool = my_auth_failover } realm LOCAL { } radiusd: #### Loading Clients #### client localhost { ipaddr = 127.0.0.1 require_message_authenticator = no secret = "testing123" nastype = "other" } client x.x.x.x { require_message_authenticator = no secret = "xxxxxxxxx" shortname = "3coms" } radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating module "exec" from file /etc/raddb/modules/exec exec { wait = no input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating module "expr" from file /etc/raddb/modules/expr Module: Linked to module rlm_expiration Module: Instantiating module "expiration" from file /etc/raddb/modules/expiration expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating module "logintime" from file /etc/raddb/modules/logintime logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server { # from file /etc/raddb/radiusd.conf modules { Module: Creating Auth-Type = digest Module: Creating Post-Auth-Type = REJECT Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating module "pap" from file /etc/raddb/modules/pap pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating module "chap" from file /etc/raddb/modules/chap Module: Linked to module rlm_mschap Module: Instantiating module "mschap" from file /etc/raddb/modules/mschap mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no allow_retry = yes } Module: Linked to module rlm_digest Module: Instantiating module "digest" from file /etc/raddb/modules/digest Module: Linked to module rlm_unix Module: Instantiating module "unix" from file /etc/raddb/modules/unix unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_eap Module: Instantiating module "eap" from file /etc/raddb/eap.conf eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 4096 } Module: Linked to sub-module rlm_eap_md5 Module: Instantiating eap-md5 Module: Linked to sub-module rlm_eap_leap Module: Instantiating eap-leap Module: Linked to sub-module rlm_eap_gtc Module: Instantiating eap-gtc gtc { challenge = "Password: " auth_type = "PAP" } Module: Linked to sub-module rlm_eap_tls Module: Instantiating eap-tls tls { rsa_key_exchange = no dh_key_exchange = yes rsa_key_length = 512 dh_key_length = 512 verify_depth = 0 CA_path = "/etc/raddb/certs" pem_file_type = yes private_key_file = "/etc/raddb/certs/server.pem" certificate_file = "/etc/raddb/certs/server.pem" CA_file = "/etc/raddb/certs/ca.pem" private_key_password = "whatever" dh_file = "/etc/raddb/certs/dh" random_file = "/etc/raddb/certs/random" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" cache { enable = no lifetime = 24 max_entries = 255 } verify { } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" } } Module: Linked to sub-module rlm_eap_ttls Module: Instantiating eap-ttls ttls { default_eap_type = "md5" copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" include_length = yes } Module: Linked to sub-module rlm_eap_peap Module: Instantiating eap-peap peap { default_eap_type = "mschapv2" copy_request_to_tunnel = no use_tunneled_reply = no proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" soh = no } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no send_error = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating module "preprocess" from file /etc/raddb/modules/preprocess preprocess { huntgroups = "/etc/raddb/huntgroups" hints = "/etc/raddb/hints" with_ascend_hack = no ascend_channels_per_line = 23 with_ntdomain_hack = no with_specialix_jetstream_hack = no with_cisco_vsa_hack = no with_alvarion_vsa_hack = no } Module: Linked to module rlm_realm Module: Instantiating module "suffix" from file /etc/raddb/modules/realm realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating module "files" from file /etc/raddb/modules/files files { usersfile = "/etc/raddb/users" acctusersfile = "/etc/raddb/acct_users" preproxy_usersfile = "/etc/raddb/preproxy_users" compat = "no" } Module: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating module "acct_unique" from file /etc/raddb/modules/acct_unique acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, Client-IP-Address, NAS-Port" } Module: Checking accounting {...} for more modules to load Module: Linked to module rlm_detail Module: Instantiating module "detail" from file /etc/raddb/modules/detail detail { detailfile = "/var/log/radius/radacct/%{%{Packet-Src-IP-Address}:-%{Packet-Src-IPv6-Address}}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_radutmp Module: Instantiating module "radutmp" from file /etc/raddb/modules/radutmp radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Linked to module rlm_attr_filter Module: Instantiating module "attr_filter.accounting_response" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.accounting_response { attrsfile = "/etc/raddb/attrs.accounting_response" key = "%{User-Name}" relaxed = no } Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Instantiating module "attr_filter.access_reject" from file /etc/raddb/modules/attr_filter attr_filter attr_filter.access_reject { attrsfile = "/etc/raddb/attrs.access_reject" key = "%{User-Name}" relaxed = no } } # modules } # server server inner-tunnel { # from file /etc/raddb/sites-enabled/inner-tunnel modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Checking session {...} for more modules to load Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load } # modules } # server radiusd: #### Opening IP addresses and Ports #### listen { type = "auth" ipaddr = * port = 0 } listen { type = "acct" ipaddr = * port = 0 } listen { type = "control" listen { socket = "/var/run/radiusd/radiusd.sock" } } listen { type = "auth" ipaddr = 127.0.0.1 port = 18120 } ... adding new socket proxy address * port 42550 Listening on authentication address * port 1812 Listening on accounting address * port 1813 Listening on command file /var/run/radiusd/radiusd.sock Listening on authentication address 127.0.0.1 port 18120 as server inner-tunnel Listening on proxy address * port 1814 Ready to process requests. rad_recv: Access-Request packet from host x.x.x.x port 1812, id=34, length=119 User-Name = "test" User-Password = "testing" NAS-IP-Address = x.x.x.x NAS-Identifier = "x.x.x.x" NAS-Port = 2562 Acct-Session-Id = "167837701" Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = "xxxxxxxxxx" Called-Station-Id = "xxxxxxx" NAS-Port-Type = Async # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "test", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop [files] users: Matched entry DEFAULT at line 172 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> test attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 2 for 1 seconds Going to the next request Waking up in 0.9 seconds. Sending delayed reject for request 2 Sending Access-Reject of id 34 to x.x.x.x port 1812 Waking up in 4.9 seconds. Cleaning up request 2 ID 34 with timestamp +122 Ready to process requests.
On 23/09/2013 18:19, paul trader wrote:
hi phil - ok, here's the full debug for a successful request:
[files] users: Matched entry test at line 1
Versus
and here's the full output of a failed request:
[files] users: Matched entry DEFAULT at line 172
The two request look very similar, but you've x.x.x.x'ed out some data (grr...). Whatever you've X'ed out, one request is matching on line 1 of the users file, one on line 172, so they're obviously different. Carefully examine the two entries on line 1 and 172, determine what's different, examine the unredacted data in the packets, and correct it.
On Mon, 23 Sep 2013 at 22:03, Phil Mayers opined: PM:Carefully examine the two entries on line 1 and 172, determine what's PM:different, examine the unredacted data in the packets, and correct it. hi phil - thanks for the advice, i figured out that placement of the $INCLUDE statement (and user info in general) in the users file is important for windows authentication. strangely enough, it doesn't seem to matter for a linux dialup, though. thanks to everyone for the help! regards, paul
paul trader wrote:
hi phil - thanks for the advice, i figured out that placement of the $INCLUDE statement (and user info in general) in the users file is important for windows authentication. strangely enough, it doesn't seem to matter for a linux dialup, though.
That is a *terrible* explanation. It's wrong and misleading. It also contradicts your previous messages. You claimed you put the "users" file entry at line one of the file. But now you talk about a $INCLUDE statement. So... which is it? Alan DeKok.
On Tue, 24 Sep 2013 at 10:36, Alan DeKok opined: AD: It also contradicts your previous messages. You claimed you put the AD:"users" file entry at line one of the file. But now you talk about a AD:$INCLUDE statement. AD: AD: So... which is it? hi alan - well, i did both. at first the $INCLUDE was put at the bottom of the users file, and there was 1 entry in the included file, at line 1. i removed the $INCLUDE statement and put the username/password entry directly in the users file, but it was at the bottom where the $INCLUDE was removed from. either way the linux clients could authenticate but not the windows ones. only after i tried moving the entry directly under the 'steve' example did it start working, so i moved the $INCLUDE statement there too. regards, paul
paul trader wrote:
hi alan - well, i did both. at first the $INCLUDE was put at the bottom of the users file, and there was 1 entry in the included file, at line 1.
Why do you have a $INCLUDE? You did NOT mention it in your other posts. The help here presumes that you accurately describe what you're doing. If you're not doing that, the help will be unhelpful.
i removed the $INCLUDE statement and put the username/password entry directly in the users file, but it was at the bottom where the $INCLUDE was removed from.
So when you were told to put the entry on line 1, you instead put it on the bottom of the file?
either way the linux clients could authenticate but not the windows ones. only after i tried moving the entry directly under the 'steve' example did it start working, so i moved the $INCLUDE statement there too.
That makes absolutely no sense. Given your other mis-statments, I think you're wrong here, too. When you follow the documentation and instructions here, it WILL WORK. Doing random other things will make it NOT WORK. I have no idea what you're doing, or what you changed to make it work. And likely neither do you. Alan DeKok.
participants (4)
-
Alan DeKok -
John Dennis -
paul trader -
Phil Mayers