LDAP (POSIX attibutes) password expiry
Hi: We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc. However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see: checkItem Expiration radiusExpiration Our LDAP attributes use the following POSIX attributes to determine expiry: shadowMax: 90 shadowLastChange: 15215 With the first being the maximum age of the password and the second being the number of days since the Epoch. I will post the obligatory debug output below (with sensitive or irrelevant stuff snipped out) for a successful authentication for an expired password that shouldn't have succeeded. If anybody has an idea how to fix this with the minimal of messing around with our LDAP config itself, I'd greatly appreciate it...or, if that's unrealistic, what should be done. TIA! # /usr/sbin/radiusd -X FreeRADIUS Version 2.1.10, for host x86_64-unknown-linux-gnu, built on Oct 26 2010 at 10:54:48 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 /usr/etc/raddb/radiusd.conf including configuration file /usr/etc/raddb/clients.conf including configuration file /usr/etc/raddb/eap.conf including configuration file /usr/etc/raddb/policy.conf including files in directory /usr/etc/raddb/sites-enabled/ including configuration file /usr/etc/raddb/sites-enabled/inner-tunnel including configuration file /usr/etc/raddb/sites-enabled/default main { user = "root" group = "wheel" allow_core_dumps = no } including dictionary file /usr/etc/raddb/dictionary main { prefix = "/usr" localstatedir = "/usr/var" logdir = "/var/log/radius" libdir = "/usr/lib" radacctdir = "/var/log/radius/radacct" hostname_lookups = no max_request_time = 30 cleanup_delay = 5 max_requests = 1024 pidfile = "/usr/var/run/radiusd/radiusd.pid" checkrad = "/usr/sbin/checkrad" debug_level = 0 proxy_requests = no log { stripped_names = no auth = yes auth_badpass = no auth_goodpass = no } security { max_attributes = 200 reject_delay = 5 status_server = yes } } radiusd: #### Loading Realms and Home Servers #### radiusd: #### Loading Clients #### client localhost { <SNIP> radiusd: #### Instantiating modules #### instantiate { Module: Linked to module rlm_exec Module: Instantiating module "exec" from file /usr/etc/raddb/radiusd.conf exec { wait = yes input_pairs = "request" shell_escape = yes } Module: Linked to module rlm_expr Module: Instantiating module "expr" from file /usr/etc/raddb/radiusd.conf Module: Linked to module rlm_expiration Module: Instantiating module "expiration" from file /usr/etc/raddb/radiusd.conf expiration { reply-message = "Password Has Expired " } Module: Linked to module rlm_logintime Module: Instantiating module "logintime" from file /usr/etc/raddb/radiusd.conf logintime { reply-message = "You are calling outside your allowed timespan " minimum-timeout = 60 } } radiusd: #### Loading Virtual Servers #### server inner-tunnel { # from file /usr/etc/raddb/sites-enabled/inner-tunnel modules { Module: Checking authenticate {...} for more modules to load Module: Linked to module rlm_pap Module: Instantiating module "pap" from file /usr/etc/raddb/radiusd.conf pap { encryption_scheme = "auto" auto_header = no } Module: Linked to module rlm_chap Module: Instantiating module "chap" from file /usr/etc/raddb/radiusd.conf Module: Linked to module rlm_mschap Module: Instantiating module "mschap" from file /usr/etc/raddb/radiusd.conf mschap { use_mppe = yes require_encryption = no require_strong = no with_ntdomain_hack = no } Module: Linked to module rlm_pam Module: Instantiating module "pam" from file /usr/etc/raddb/radiusd.conf pam { pam_auth = "radiusd-auth" } Module: Linked to module rlm_unix Module: Instantiating module "unix" from file /usr/etc/raddb/radiusd.conf unix { radwtmp = "/var/log/radius/radwtmp" } Module: Linked to module rlm_ldap Module: Instantiating module "ldap1" from file /usr/etc/raddb/radiusd.conf ldap ldap1 { server = "ldap.server" port = 389 password = "" identity = "" net_timeout = 1 timeout = 4 timelimit = 3 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" auto_header = no access_attr_used_for_allow = yes groupname_attribute = "cn" groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" dictionary_mapping = "/usr/etc/raddb/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes set_auth_type = no } rlm_ldap: Registering ldap_groupcmp for Ldap-Group rlm_ldap: Creating new attribute ldap1-Ldap-Group rlm_ldap: Registering ldap_groupcmp for ldap1-Ldap-Group rlm_ldap: Registering ldap_xlat with xlat_name ldap1 rlm_ldap: reading ldap<->radius mappings from file /usr/etc/raddb/ldap.attrmap rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password rlm_ldap: LDAP sambaLmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP sambaNtPassword mapped to RADIUS NT-Password rlm_ldap: LDAP acctFlags mapped to RADIUS SMB-Account-CTRL-TEXT rlm_ldap: LDAP radiusExpiration mapped to RADIUS Expiration rlm_ldap: LDAP radiusNASIpAddress mapped to RADIUS NAS-IP-Address rlm_ldap: LDAP radiusServiceType mapped to RADIUS Service-Type rlm_ldap: LDAP radiusFramedProtocol mapped to RADIUS Framed-Protocol rlm_ldap: LDAP radiusFramedIPAddress mapped to RADIUS Framed-IP-Address rlm_ldap: LDAP radiusFramedIPNetmask mapped to RADIUS Framed-IP-Netmask rlm_ldap: LDAP radiusFramedRoute mapped to RADIUS Framed-Route rlm_ldap: LDAP radiusFramedRouting mapped to RADIUS Framed-Routing rlm_ldap: LDAP radiusFilterId mapped to RADIUS Filter-Id rlm_ldap: LDAP radiusFramedMTU mapped to RADIUS Framed-MTU rlm_ldap: LDAP radiusFramedCompression mapped to RADIUS Framed-Compression rlm_ldap: LDAP radiusLoginIPHost mapped to RADIUS Login-IP-Host rlm_ldap: LDAP radiusLoginService mapped to RADIUS Login-Service rlm_ldap: LDAP radiusLoginTCPPort mapped to RADIUS Login-TCP-Port rlm_ldap: LDAP radiusCallbackNumber mapped to RADIUS Callback-Number rlm_ldap: LDAP radiusCallbackId mapped to RADIUS Callback-Id rlm_ldap: LDAP radiusFramedIPXNetwork mapped to RADIUS Framed-IPX-Network rlm_ldap: LDAP radiusClass mapped to RADIUS Class rlm_ldap: LDAP radiusSessionTimeout mapped to RADIUS Session-Timeout rlm_ldap: LDAP radiusIdleTimeout mapped to RADIUS Idle-Timeout rlm_ldap: LDAP radiusTerminationAction mapped to RADIUS Termination-Action rlm_ldap: LDAP radiusLoginLATService mapped to RADIUS Login-LAT-Service rlm_ldap: LDAP radiusLoginLATNode mapped to RADIUS Login-LAT-Node rlm_ldap: LDAP radiusLoginLATGroup mapped to RADIUS Login-LAT-Group rlm_ldap: LDAP radiusFramedAppleTalkLink mapped to RADIUS Framed-AppleTalk-Link rlm_ldap: LDAP radiusFramedAppleTalkNetwork mapped to RADIUS Framed-AppleTalk-Network rlm_ldap: LDAP radiusFramedAppleTalkZone mapped to RADIUS Framed-AppleTalk-Zone rlm_ldap: LDAP radiusPortLimit mapped to RADIUS Port-Limit rlm_ldap: LDAP radiusLoginLATPort mapped to RADIUS Login-LAT-Port rlm_ldap: LDAP radiusReplyMessage mapped to RADIUS Reply-Message conns: 0x13fb4be0 Module: Instantiating module "ldap2" from file /usr/etc/raddb/radiusd.conf ldap ldap2 { server = "secondary.ldap.server" port = 389 password = "" identity = "" net_timeout = 1 timeout = 4 timelimit = 3 tls_mode = no start_tls = no tls_require_cert = "allow" tls { start_tls = no require_cert = "allow" } basedn = "dc=domain,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" base_filter = "(objectclass=radiusprofile)" auto_header = no access_attr_used_for_allow = yes groupname_attribute = "cn" groupmembership_filter = "(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))" dictionary_mapping = "/usr/etc/raddb/ldap.attrmap" ldap_debug = 0 ldap_connections_number = 5 compare_check_items = no do_xlat = yes set_auth_type = no } rlm_ldap: Registering ldap_groupcmp for Ldap-Group rlm_ldap: Creating new attribute ldap2-Ldap-Group rlm_ldap: Registering ldap_groupcmp for ldap2-Ldap-Group rlm_ldap: Registering ldap_xlat with xlat_name ldap2 rlm_ldap: reading ldap<->radius mappings from file /usr/etc/raddb/ldap.attrmap rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$ rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password rlm_ldap: LDAP sambaLmPassword mapped to RADIUS LM-Password rlm_ldap: LDAP sambaNtPassword mapped to RADIUS NT-Password rlm_ldap: LDAP acctFlags mapped to RADIUS SMB-Account-CTRL-TEXT rlm_ldap: LDAP radiusExpiration mapped to RADIUS Expiration rlm_ldap: LDAP radiusNASIpAddress mapped to RADIUS NAS-IP-Address rlm_ldap: LDAP radiusServiceType mapped to RADIUS Service-Type rlm_ldap: LDAP radiusFramedProtocol mapped to RADIUS Framed-Protocol rlm_ldap: LDAP radiusFramedIPAddress mapped to RADIUS Framed-IP-Address rlm_ldap: LDAP radiusFramedIPNetmask mapped to RADIUS Framed-IP-Netmask rlm_ldap: LDAP radiusFramedRoute mapped to RADIUS Framed-Route rlm_ldap: LDAP radiusFramedRouting mapped to RADIUS Framed-Routing rlm_ldap: LDAP radiusFilterId mapped to RADIUS Filter-Id rlm_ldap: LDAP radiusFramedMTU mapped to RADIUS Framed-MTU rlm_ldap: LDAP radiusFramedCompression mapped to RADIUS Framed-Compression rlm_ldap: LDAP radiusLoginIPHost mapped to RADIUS Login-IP-Host rlm_ldap: LDAP radiusLoginService mapped to RADIUS Login-Service rlm_ldap: LDAP radiusLoginTCPPort mapped to RADIUS Login-TCP-Port rlm_ldap: LDAP radiusCallbackNumber mapped to RADIUS Callback-Number rlm_ldap: LDAP radiusCallbackId mapped to RADIUS Callback-Id rlm_ldap: LDAP radiusFramedIPXNetwork mapped to RADIUS Framed-IPX-Network rlm_ldap: LDAP radiusClass mapped to RADIUS Class rlm_ldap: LDAP radiusSessionTimeout mapped to RADIUS Session-Timeout rlm_ldap: LDAP radiusIdleTimeout mapped to RADIUS Idle-Timeout rlm_ldap: LDAP radiusTerminationAction mapped to RADIUS Termination-Action rlm_ldap: LDAP radiusLoginLATService mapped to RADIUS Login-LAT-Service rlm_ldap: LDAP radiusLoginLATNode mapped to RADIUS Login-LAT-Node rlm_ldap: LDAP radiusLoginLATGroup mapped to RADIUS Login-LAT-Group rlm_ldap: LDAP radiusFramedAppleTalkLink mapped to RADIUS Framed-AppleTalk-Link rlm_ldap: LDAP radiusFramedAppleTalkNetwork mapped to RADIUS Framed-AppleTalk-Network rlm_ldap: LDAP radiusFramedAppleTalkZone mapped to RADIUS Framed-AppleTalk-Zone rlm_ldap: LDAP radiusPortLimit mapped to RADIUS Port-Limit rlm_ldap: LDAP radiusLoginLATPort mapped to RADIUS Login-LAT-Port rlm_ldap: LDAP radiusReplyMessage mapped to RADIUS Reply-Message conns: 0x13fb66e0 Module: Linked to module rlm_eap Module: Instantiating module "eap" from file /usr/etc/raddb/eap.conf eap { default_eap_type = "md5" timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = 2048 } 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 pem_file_type = yes private_key_file = "/usr/etc/raddb/certs/server.pem" certificate_file = "/usr/etc/raddb/certs/server.pem" CA_file = "/usr/etc/raddb/certs/ca.pem" private_key_password = "whatever" dh_file = "/usr/etc/raddb/certs/dh" random_file = "/usr/etc/raddb/certs/random" fragment_size = 1024 include_length = yes check_crl = no cipher_list = "DEFAULT" make_cert_command = "/usr/etc/raddb/certs/bootstrap" } 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" } Module: Linked to sub-module rlm_eap_mschapv2 Module: Instantiating eap-mschapv2 mschapv2 { with_ntdomain_hack = no } Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_realm Module: Instantiating module "suffix" from file /usr/etc/raddb/radiusd.conf realm suffix { format = "suffix" delimiter = "@" ignore_default = no ignore_null = no } Module: Linked to module rlm_files Module: Instantiating module "files" from file /usr/etc/raddb/radiusd.conf files { usersfile = "/usr/etc/raddb/users" acctusersfile = "/usr/etc/raddb/acct_users" preproxy_usersfile = "/usr/etc/raddb/preproxy_users" compat = "no" } Module: Checking session {...} for more modules to load Module: Linked to module rlm_radutmp Module: Instantiating module "radutmp" from file /usr/etc/raddb/radiusd.conf radutmp { filename = "/var/log/radius/radutmp" username = "%{User-Name}" case_sensitive = yes check_with_nas = yes perm = 384 callerid = yes } Module: Checking post-proxy {...} for more modules to load Module: Checking post-auth {...} for more modules to load Module: Linked to module rlm_attr_filter Module: Instantiating module "attr_filter.access_reject" from file /usr/etc/raddb/radiusd.conf attr_filter attr_filter.access_reject { attrsfile = "/usr/etc/raddb/attrs.access_reject" key = "%{User-Name}" } } # modules } # server server { # from file /usr/etc/raddb/radiusd.conf modules { Module: Checking authenticate {...} for more modules to load Module: Checking authorize {...} for more modules to load Module: Linked to module rlm_preprocess Module: Instantiating module "preprocess" from file /usr/etc/raddb/radiusd.conf preprocess { huntgroups = "/usr/etc/raddb/huntgroups" hints = "/usr/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: Checking preacct {...} for more modules to load Module: Linked to module rlm_acct_unique Module: Instantiating module "acct_unique" from file /usr/etc/raddb/radiusd.conf 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 /usr/etc/raddb/radiusd.conf detail { detailfile = "/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d" header = "%t" detailperm = 384 dirperm = 493 locking = no log_packet_header = no } Module: Linked to module rlm_ippool Module: Instantiating module "some_pool" from file /usr/etc/raddb/radiusd.conf <SNIP> } Module: Instantiating module "attr_filter.accounting_response" from file /usr/etc/raddb/radiusd.conf attr_filter attr_filter.accounting_response { attrsfile = "/usr/etc/raddb/attrs.accounting_response" key = "%{User-Name}" } 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 = 1812 } listen { type = "acct" ipaddr = * port = 1813 } Listening on authentication address * port 1812 Listening on accounting address * port 1813 Ready to process requests. rad_recv: Access-Request packet from host 192.168.7.1 port 1645, id=225, length=97 Framed-Protocol = PPP User-Name = "ldaptest" User-Password = "testing" NAS-Port-Type = Virtual NAS-Port = 241 NAS-Port-Id = "Uniq-Sess-ID241" Service-Type = Framed-User NAS-IP-Address = 192.168.bogus # Executing section authorize from file /usr/etc/raddb/sites-enabled/default +- entering group authorize {...} ++[preprocess] returns ok ++- entering group LDAP {...} [ldap1] performing user authorization for ldaptest [ldap1] WARNING: Deprecated conditional expansion ":-". See "man unlang" for details [ldap1] ... expanding second conditional [ldap1] expand: %{User-Name} -> ldaptest [ldap1] expand: (uid=%{Stripped-User-Name:-%{User-Name}}) -> (uid=ldaptest) [ldap1] expand: dc=domain,dc=com -> dc=domain,dc=com [ldap1] ldap_get_conn: Checking Id: 0 [ldap1] ldap_get_conn: Got Id: 0 [ldap1] attempting LDAP reconnection [ldap1] (re)connect to ldap.server:389, authentication 0 [ldap1] bind as / to ldap.server:389 [ldap1] waiting for bind result ... [ldap1] Bind was successful [ldap1] performing search in dc=domain,dc=com, with filter (uid=ldaptest) [ldap1] looking for check items in directory... [ldap1] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap1] user ldaptest authorized to use remote access [ldap1] ldap_release_conn: Release Id: 0 +++[ldap1] returns ok ++- group LDAP returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "ldaptest", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns updated [files] users: Matched entry DEFAULT at line 237 ++[files] returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING: Auth-Type already set. Not setting to PAP ++[pap] returns noop Found Auth-Type = LDAP # Executing group from file /usr/etc/raddb/sites-enabled/default +- entering group authenticate {...} ++- entering group LDAP {...} [ldap1] login attempt by "ldaptest" with password "testing" [ldap1] user DN: uid=ldaptest,ou=People,dc=domain,dc=com [ldap1] (re)connect to ldap.server:389, authentication 1 [ldap1] bind as uid=ldaptest,ou=People,dc=domain,dc=com/testing to ldap.server:389 [ldap1] waiting for bind result ... [ldap1] Bind was successful [ldap1] user ldaptest authenticated succesfully +++[ldap1] returns ok ++- group LDAP returns ok Login OK: [ldaptest] (from client cisco_pptp port 241) # Executing section post-auth from file /usr/etc/raddb/sites-enabled/default +- entering group post-auth {...} [medium_pool] Could not find Pool-Name attribute. ++[medium_pool] returns noop [super_pool] Could not find Pool-Name attribute. ++[super_pool] returns noop [student_pool] Could not find Pool-Name attribute. ++[student_pool] returns noop [euro_pool] Could not find Pool-Name attribute. ++[euro_pool] returns noop ++[exec] returns noop Sending Access-Accept of id 225 to 192.168.Bogus port 1645 Framed-Protocol == PPP Framed-Compression = Van-Jacobson-TCP-IP Cisco-AVPair = "ip:addr-pool=vpnpool" Finished request 0.
up@3.am wrote:
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Did you check that the LDAP module is returning this attribute for the query? Did you check that Expiration works if you put it into the "users" file? Did you check that the LDAP module is returning the expiration attribute in the format undestood by FreeRADIUS? Read the debug log. The "expiration" module is returning NOOP. It only returns NOOP if there is no Expiration attribute. Alan DeKok.
up@3.am wrote:
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Did you check that the LDAP module is returning this attribute for the query?
No, I don't expect it to, since I don't have that attribute or anything that looks like it might be a good substitute.
Did you check that Expiration works if you put it into the "users" file?
I'm not worried about that...expiry worked with the old rlm_pam using Unix expiry. When exporting Unix to LDAP, the expiry data was exported from /etc/shadow to the two LDAP attributes mentioned. I was hoping that perhaps there was a module that could calculate between the two and figure out that the password was expired and take it from there. I figured it a long shot but worth asking. Thanks!
up@3.am wrote:
checkItem Expiration radiusExpiration Did you check that the LDAP module is returning this attribute for the query?
No, I don't expect it to, since I don't have that attribute or anything that looks like it might be a good substitute.
So... why would you ever expect that expiration will work?
Did you check that Expiration works if you put it into the "users" file?
I'm not worried about that...expiry worked with the old rlm_pam using Unix expiry.
I see. You ask for help, and you ignore the response. If you do this again, you will be unsubscribed and banned.
When exporting Unix to LDAP, the expiry data was exported from /etc/shadow to the two LDAP attributes mentioned. I was hoping that perhaps there was a module that could calculate between the two and figure out that the password was expired and take it from there. I figured it a long shot but worth asking.
Was there documentation saying that such a module existed? Alan DeKok.
up@3.am wrote:
checkItem Expiration radiusExpiration Did you check that the LDAP module is returning this attribute for the query?
No, I don't expect it to, since I don't have that attribute or anything that looks like it might be a good substitute.
So... why would you ever expect that expiration will work?
I expect it would take some fiddling. I was showing what I had done so far for background reference. From a couple of other responses, it appears there might be ways to get this working.
Did you check that Expiration works if you put it into the "users" file?
I'm not worried about that...expiry worked with the old rlm_pam using Unix expiry.
I see. You ask for help, and you ignore the response.
I didn't ignore any response. I have no reason to worry about whether Expiration will work in "users" because A) I'm not using users, I'm using LDAP and B) expiry worked fine using rlm_pam and /etc/shadow. My first thought (hope) was that there was some config option in rlm_ldap that I was missing that might be an easy fix. I knew it was a long shot, but I didn't see the harm in asking.
If you do this again, you will be unsubscribed and banned.
Alan: I have been using your software for many years, and received a lot of help from you and other members of this list and know you have little patience for requests for help that don't include adequate debug output and inclusion of relevant configuration information. I've obviously pissed you off with my reply to you and for that, I apologize. It was not my intention. My cognitive ability is still recovering from a lot of chemotherapy over the past year and this may be reflected in the way I parse and post.
When exporting Unix to LDAP, the expiry data was exported from /etc/shadow to the two LDAP attributes mentioned. I was hoping that perhaps there was a module that could calculate between the two and figure out that the password was expired and take it from there. I figured it a long shot but worth asking.
Was there documentation saying that such a module existed?
Not that I could find, hence my post here. It looks like more clueful people than I have some potential workarounds, so from that standpoint, it may have paid off.
up@3.am wrote:
I didn't ignore any response. I have no reason to worry about whether Expiration will work in "users" because A) I'm not using users, I'm using LDAP and B) expiry worked fine using rlm_pam and /etc/shadow.
Once again, you completely misunderstand my point. This is rude. You asked *explicitly* about the Expiration attribute. FreeRADIUS implements expiration via the expiration attribute. I gave you instructions for testing it. Your response was to assume I'm an idiot, and to ignore my attempt to help you. You assumed I had no idea what you're talking about. You assumed I was confused about how FreeRADIUS works.
Alan: I have been using your software for many years, and received a lot of help from you and other members of this list and know you have little patience for requests for help that don't include adequate debug output and inclusion of relevant configuration information.
No. I have little patience for people who ask for help, and then tell me I'm wrong. If you're so smart, why are you asking questions here? Your behavior is rude. When I point this out, you get offended.
Not that I could find, hence my post here. It looks like more clueful people than I have some potential workarounds, so from that standpoint, it may have paid off.
Maybe they successfully read your mind. I know I can't. I answered the question you asked. Your response was to tell me my help was bullsh*t. That behavior is antisocial. Antisocial people get banned from this list. Alan DeKok.
up@3.am wrote:
I didn't ignore any response. I have no reason to worry about whether Expiration will work in "users" because A) I'm not using users, I'm using LDAP and B) expiry worked fine using rlm_pam and /etc/shadow.
Once again, you completely misunderstand my point. This is rude.
I am sorry, I did not mean to be rude. You're right, I misunderstood your point.
You asked *explicitly* about the Expiration attribute. FreeRADIUS implements expiration via the expiration attribute. I gave you instructions for testing it.
Your response was to assume I'm an idiot, and to ignore my attempt to help you. You assumed I had no idea what you're talking about. You assumed I was confused about how FreeRADIUS works.
Not at all. I know that you know better than anyone how FreeRADIUS works. I thought you were understandably unclear about what I was asking, because I obviously wasn't asking it well.
Alan: I have been using your software for many years, and received a lot of help from you and other members of this list and know you have little patience for requests for help that don't include adequate debug output and inclusion of relevant configuration information.
No. I have little patience for people who ask for help, and then tell me I'm wrong. If you're so smart, why are you asking questions here?
Your behavior is rude. When I point this out, you get offended.
I wasn't offended, I was apologetic and tried to offer an explanation for my current cognitive difficulties (perhaps you missed that part, because it was removed in your reply). I am a little taken aback by how much I have apparently offended you.
Not that I could find, hence my post here. It looks like more clueful people than I have some potential workarounds, so from that standpoint, it may have paid off.
Maybe they successfully read your mind. I know I can't.
I answered the question you asked. Your response was to tell me my help was bullsh*t.
I never said that, come on. Again, this is all due to my asking the wrong question or asking it in the wrong way. I can see why this upset you. You took the time to actually read my poorly put question and read debug output which really had no relevance, since nothing is really broken. At least that's how I see it. Again, I am sorry.
That behavior is antisocial. Antisocial people get banned from this list.
Well, I hope you don't ban me. I don't think that's happened to me in 20 years. I am sorry that I came off as antisocial. It was not my intention.
Alan DeKok. -
up@3.am wrote:
I wasn't offended, I was apologetic and tried to offer an explanation for my current cognitive difficulties (perhaps you missed that part, because it was removed in your reply). I am a little taken aback by how much I have apparently offended you.
It's not that I'm offended. It's that I've had enough of people asking questions, and arguing with the answers. I'm assuming that people ask questions because they honestly want help. I respond in that manner. When I get told that my answer is wrong, I tell people that they can be unsubscribed for wasting everyone's time.
Well, I hope you don't ban me. I don't think that's happened to me in 20 years. I am sorry that I came off as antisocial. It was not my intention.
I know. To explain why certain things are antisocial, look at the following story. --- You're standing on a corner, waiting to cross the street. A car stops at the light in front of you. The passenger asks for directions. You say "Sure! One block ahead, you can't miss it!" When the light goes green, the car does a U-turn, and goes back the way it came. Your response is probably to think bad thoughts about people in the car. And then the next day, you see the same car at the same corner. They do the same thing. The third day this happens, you tell the passenger "You know what, you're not interested in my help. Go figure it out yourself." The passenger then gets angry at you for being rude and unhelpful. --- The rules of this list are simple. Ask questions. Read the answers. Follow the instructions. People wasting our time will get unsubscribed. Alan DeKok.
On Wed, Feb 29, 2012 at 4:16 AM, <up@3.am> wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
With the first being the maximum age of the password and the second being the number of days since the Epoch. I will post the obligatory debug output below (with sensitive or irrelevant stuff snipped out) for a successful authentication for an expired password that shouldn't have succeeded. If anybody has an idea how to fix this with the minimal of messing around with our LDAP config itself, I'd greatly appreciate it...or, if that's unrealistic, what should be done. TIA!
IIRC the Expiration attribute requires the format of "01 Jan 2011 01:00:00" (or something like that, other format might work, test it first). From the two LDAP attributes, you should be able to process them and present it as a new attribute. I see no easy way to do that without additional module though. You COULD use something like this on ldap.attrmap: checkItem Tmp-Integer-0 shadowMax checkItem Tmp-Integer-1 shadowLastChange ... then convert it to expiration with rlm_perl/rlm_sql/whatever. If you already have a mysql instance (e.g. for accounting), you could probably use it to do the processing. Something like this (see http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html): update control { Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} + %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" } -- Fajar
On Wed, Feb 29, 2012 at 6:11 AM, Fajar A. Nugraha <list@fajar.net> wrote:
On Wed, Feb 29, 2012 at 4:16 AM, <up@3.am> wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
With the first being the maximum age of the password and the second being the number of days since the Epoch. I will post the obligatory debug output below (with sensitive or irrelevant stuff snipped out) for a successful authentication for an expired password that shouldn't have succeeded. If anybody has an idea how to fix this with the minimal of messing around with our LDAP config itself, I'd greatly appreciate it...or, if that's unrealistic, what should be done. TIA!
IIRC the Expiration attribute requires the format of "01 Jan 2011 01:00:00" (or something like that, other format might work, test it first). From the two LDAP attributes, you should be able to process them and present it as a new attribute.
I see no easy way to do that without additional module though. You COULD use something like this on ldap.attrmap:
checkItem Tmp-Integer-0 shadowMax checkItem Tmp-Integer-1 shadowLastChange
... then convert it to expiration with rlm_perl/rlm_sql/whatever. If you already have a mysql instance (e.g. for accounting), you could probably use it to do the processing. Something like this (see http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html):
update control { Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} + %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" }
Sorry. Should be something like update control { Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{control:Tmp-Integer-0} + %{control:Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" } -- Fajar
On Wed, Feb 29, 2012 at 4:16 AM, <up@3.am> wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
With the first being the maximum age of the password and the second being the number of days since the Epoch. I will post the obligatory debug output below (with sensitive or irrelevant stuff snipped out) for a successful authentication for an expired password that shouldn't have succeeded. If anybody has an idea how to fix this with the minimal of messing around with our LDAP config itself, I'd greatly appreciate it...or, if that's unrealistic, what should be done. TIA!
IIRC the Expiration attribute requires the format of "01 Jan 2011 01:00:00" (or something like that, other format might work, test it first). From the two LDAP attributes, you should be able to process them and present it as a new attribute.
I see no easy way to do that without additional module though. You COULD use something like this on ldap.attrmap:
checkItem Tmp-Integer-0 shadowMax checkItem Tmp-Integer-1 shadowLastChange
... then convert it to expiration with rlm_perl/rlm_sql/whatever. If you already have a mysql instance (e.g. for accounting), you could probably use it to do the processing. Something like this (see http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html):
update control { Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} + %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" }
Fajar, thanks for taking the time with this reply. No, I'm not running MySQL for accounting...just the standard flat files on separate remote server and of course for auth, LDAP. I'll have to take a look and see what rlm_perl can do for us. I don't see a problem getting the attributes using perl (even if it just invokes shell commands), but how to process it back to FreeRADIUS without interfering with anything else.
On Wed, Feb 29, 2012 at 8:37 AM, <up@3.am> wrote:
On Wed, Feb 29, 2012 at 4:16 AM, <up@3.am> wrote:
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
With the first being the maximum age of the password and the second being the number of days since the Epoch. I will post the obligatory debug output below (with sensitive or irrelevant stuff snipped out) for a successful authentication for an expired password that shouldn't have succeeded. If anybody has an idea how to fix this with the minimal of messing around with our LDAP config itself, I'd greatly appreciate it...or, if that's unrealistic, what should be done. TIA!
IIRC the Expiration attribute requires the format of "01 Jan 2011 01:00:00" (or something like that, other format might work, test it first). From the two LDAP attributes, you should be able to process them and present it as a new attribute.
I see no easy way to do that without additional module though. You COULD use something like this on ldap.attrmap:
checkItem Tmp-Integer-0 shadowMax checkItem Tmp-Integer-1 shadowLastChange
... then convert it to expiration with rlm_perl/rlm_sql/whatever. If you already have a mysql instance (e.g. for accounting), you could probably use it to do the processing. Something like this (see http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html):
update control { Expiration := "%{sql: SELECT FROM_UNIXTIME( ( %{Tmp-Integer-0} + %{Tmp-Integer-1} ) * 86400, '%d %b %Y %H:%i%s' )}" }
Fajar, thanks for taking the time with this reply. No, I'm not running MySQL for accounting...just the standard flat files on separate remote server and of course for auth, LDAP. I'll have to take a look and see what rlm_perl can do for us. I don't see a problem getting the attributes using perl (even if it just invokes shell commands), but how to process it back to FreeRADIUS without interfering with anything else.
Rlm_exec should be straight forward: http://wiki.freeradius.org/Rlm_exec However it may incur performance penalty on busy sites. Rlm_perl should be cleaner, basically you just work with %RAD_CHECK: http://wiki.freeradius.org/Rlm_perl rlm_sql is an easy one-liner solution. It should work even if you're not usiing it for auth/acct, as long as it's instantiated (manually if necessary, see radiusd.conf). But in your case it might be awkward as you're basically only using it as a programming languange :P -- Fajar
On 28/02/12 21:16, up@3.am wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
Other replies should have convinced you that there's no built-in support for this. You will need to either: 1. Arrange for a FreeRADIUS-ready "radiusExpiration" attribute to be set in LDAP alongside the POSIX/shadow schemas 2. Synthesize an Expiration attribute, or otherwise locally check the POSIX/shadow attributes. One way you might accomplish the 2nd is as follows: == Create some local RADIUS attributes for the shadow values == /etc/raddb/dictionary: ATTRIBUTE Shadow-Max-Age 3000 integer ATTRIBUTE Shadow-Last-Change 3001 integer ATTRIBUTE Shadow-Expires 3002 integer ATTRIBUTE Shadow-Current 3003 integer /etc/raddb/ldap.attrmap: checkItem Shadow-Max-Age shadowMax checkItem Shadow-Last-Change shadowLastChange == Read these attributes from LDAP, then perform some maths == /etc/raddb/sites-enabled/<server>: authorize { ... ldap update control { Shadow-Expires := "%{expr:%{control:Shadow-Last-Change} + %{control:Shadow-Max-Age}}" Shadow-Current := "%{expr:%l / 86400}" } if (control:Shadow-Current > control:Shadow-Expires) { reject } ... } Hopefully it's clear what this does, but basically: 1. Pulls last-change & max-age from LDAP 2. Adds them together, to get expiry (in days since epoch) 3. Divides %l (epoch) by 86400 to get today, in days since epoch 4. Compares them
On 28/02/12 21:16, up@3.am wrote:
Hi:
We've been running various versions of FreeRadius for years, currently 2.1.10 in this application. A while ago, we switched from PAM (unix) auth to LDAP auth. Everything worked fine after the switch...POSIX attributes for group membership correctly allocated the right ippools, etc.
However, we just noticed that password expiry isn't working. I suspect this is because we are still using all the original POSIX attributes and none of them look like good for mapping to the ones supplied by FreeRADIUS. I see:
checkItem Expiration radiusExpiration
Our LDAP attributes use the following POSIX attributes to determine expiry:
shadowMax: 90 shadowLastChange: 15215
Other replies should have convinced you that there's no built-in support for this. You will need to either:
1. Arrange for a FreeRADIUS-ready "radiusExpiration" attribute to be set in LDAP alongside the POSIX/shadow schemas
2. Synthesize an Expiration attribute, or otherwise locally check the POSIX/shadow attributes.
One way you might accomplish the 2nd is as follows:
== Create some local RADIUS attributes for the shadow values ==
/etc/raddb/dictionary:
ATTRIBUTE Shadow-Max-Age 3000 integer ATTRIBUTE Shadow-Last-Change 3001 integer ATTRIBUTE Shadow-Expires 3002 integer ATTRIBUTE Shadow-Current 3003 integer
/etc/raddb/ldap.attrmap:
checkItem Shadow-Max-Age shadowMax checkItem Shadow-Last-Change shadowLastChange
== Read these attributes from LDAP, then perform some maths ==
/etc/raddb/sites-enabled/<server>:
authorize { ... ldap update control { Shadow-Expires := "%{expr:%{control:Shadow-Last-Change} + %{control:Shadow-Max-Age}}" Shadow-Current := "%{expr:%l / 86400}" } if (control:Shadow-Current > control:Shadow-Expires) { reject } ... }
Hopefully it's clear what this does, but basically:
1. Pulls last-change & max-age from LDAP 2. Adds them together, to get expiry (in days since epoch) 3. Divides %l (epoch) by 86400 to get today, in days since epoch 4. Compares them -
It's very clear...I had no idea that the ldap module could do math functions. This is just the kind of thing I was looking for. Thanks!
participants (4)
-
Alan DeKok -
Fajar A. Nugraha -
Phil Mayers -
up＠3.am