- Freeradius-Users - lists.freeradius.org

Re: How to differentiate between vpn user and appliance user?
by D C 27 Jul '15

27 Jul '15

On Fri, Jul 24, 2015 at 8:02 AM, D C <dc12078(a)gmail.com> wrote: > I recently configured a radius server with openldap backend to handle > central auth for all my network equipment. The ldap module is using > "radiusGroupName" as my groupmembership_attribute. > > I've configured post-auth and the users file in such a way that I can log > into devices with my ldap credentials ONLY if I am a member of one of 2 > groups. My reply-item attributes are stored in ldap within the group, and > all that is working great. Valid users who are not members of these > defined groups get rejected. perfect. > > Now the tricky part. I have a third ldap group that i want to use in > order to assign vpn access to people. so some users may be members of only > the vpn group, and some maybe members of the superadmin group as well as > the vpn group. This causes two problems. > > 1) If I add allow the vpn group, then vpn users will be able to login to > network equipment which is definitely not desired. > > 2) I don't currently have any way to determine within radius if a user is > trying to login to the vpn, or if they are trying to ssh to my firewall. > > > I'm not really sure what I should do to work around this. My only idea > I've come up with (which I don't like), is to have my firewall set a > different NAS-ip for the vpn users. If that is different, then I imagine I > can probably write some login in post-auth to handle it. Is there a better > way to do this. > > > The radius configuration on my firewall will let me set the nas-ip, > auth-type, which source ip to communicate with, and which destination port > the radius server is listening on. I've not yet looked into how the > virtual servers work in radius, so maybe I can setup a different port and > config for my vpn users to auth against.. > > > Using FreeRadius 2.1.12. > Sorry for re posting, I just realized I never set a subject...

3 11

freeradius 2.1.12 - EAP Trouble - files is used with LEAP, not PEAP, and AD/mschap is used with PEAP, not LEAP
by freerad 27 Jul '15

27 Jul '15

# freeradius -v freeradius: FreeRADIUS Version 2.1.12, for host x86_64-pc-linux-gnu, built on Feb 24 2014 at 14:57:57 Copyright (C) 1999-2011 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. For more information about these matters, see the file named COPYRIGHT. /etc/freeradius/files contains: *testuser Cleartext-Password := "password"* # radexample with user "testuser" and password "password" - as it exists in /etc/freeradius/users works: # radexample login: testuser Password: password "testuser" RADIUS Authentication OK (log01.txt) but # ./rad_eap_test -H 10.160.4.50 -P 1812 -S testing123 -u testuser -p password -m IEEE8021X -e PEAP -2 MSCHAPV2 -v access-reject; 1 fails (log02.txt), but I wanted to have it handled by "files". but with LEAP it works: # ./rad_eap_test -H 10.160.4.50 -P 1812 -S testing123 -u testuser -p password -m IEEE8021X -e LEAP -2 MSCHAPV2 -v access-accept; 0 RADIUS message: code=2 (Access-Accept) identifier=3 length=149 Attribute 26 (Vendor-Specific) length=59 Value: 00 00 00 09 01 35 6c 65 61 70 3a 73 65 73 73 69 6f 6e 2d 6b 65 79 3d 82 68 87 56 16 2a 3d 5a 79 ae c4 db ee d3 2c db 38 83 9a 9f 81 a7 70 03 55 00 c4 b1 cb 45 78 ea ce 63 Attribute 79 (EAP-Message) length=42 Value: 02 04 00 28 11 01 00 18 24 16 99 a0 97 e6 72 86 eb 2d 2e 97 5a ef 9c c7 e2 00 cf b4 95 8a fa 42 74 65 73 74 75 73 65 72 Attribute 80 (Message-Authenticator) length=18 Value: e2 d3 98 f4 75 a9 44 6b 04 e2 d8 ef 6b 54 4f b1 Attribute 1 (User-Name) length=10 Value: 'testuser' (log03.txt). And - with AD User, LEAP does not work # ./rad_eap_test -H 10.160.4.50 -P 1812 -S testing123 -u wlan_test -p test -m IEEE8021X -e LEAP -2 MSCHAPV2 -v access-reject; 1 (log04.txt) while with AD User PEAP is working: # ./rad_eap_test -H 10.160.4.50 -P 1812 -S testing123 -u wlan_test -p test -m IEEE8021X -e PEAP -2 MSCHAPV2 -v access-accept; 0 RADIUS message: code=2 (Access-Accept) identifier=9 length=171 Attribute 26 (Vendor-Specific) length=58 Value: 00 00 01 37 11 34 81 3f 5f f6 c1 df a3 6f 6e bc 39 89 09 c8 5f da bd a7 e4 86 45 0e a9 b7 b1 e9 0d 88 1a 4c 15 d7 9a 8a db 25 87 bd 4f b2 33 11 e6 b2 0b 68 b1 c6 7f 91 Attribute 26 (Vendor-Specific) length=58 Value: 00 00 01 37 10 34 89 ca ed f6 a0 75 fc 03 b8 91 24 91 ab a0 ba ae 25 72 b0 66 6d b0 69 b0 72 43 83 61 c2 30 fc 4c 62 9f 44 5c 23 00 c3 1b 40 d3 cf 12 3c 55 4d dd 4a 93 Attribute 79 (EAP-Message) length=6 Value: 03 09 00 04 Attribute 80 (Message-Authenticator) length=18 Value: e9 5f 92 1a 6f 01 26 29 b2 b3 9c 87 61 e8 e3 ca Attribute 1 (User-Name) length=11 Value: 'wlan_test' What is wrong here? I want to handle first files, then mschap/ntlm_auth Authentication. Any help is appreciated. Thomas

3 5

eapol_test with TLS fails (nothing sent to freeradius)
by freerad 27 Jul '15

27 Jul '15

This command fails with timout: config file: rad_eap_test.txt network={ ssid="eduroam" key_mgmt=IEEE8021X eap=TLS ca_cert="ca.pem" identity="wlan_test" password="test" client_cert="client.pem" private_key="client.key" } Openssl verify is ok: # openssl verify -CAfile ca.pem client.pem client.pem: OK # bin/eapol_test -crad_eap_test.txt -a10.160.4.50 -p1812 -stesting123 -test -M70:6f:6c:69:73:68 Reading configuration file 'rad_eap_test.txt' Line: 1 - start of a new network block ssid - hexdump_ascii(len=7): 65 64 75 72 6f 61 6d eduroam key_mgmt: 0x8 eap methods - hexdump(len=16): 00 00 00 00 0d 00 00 00 00 00 00 00 00 00 00 00 ca_cert - hexdump_ascii(len=6): 63 61 2e 70 65 6d ca.pem identity - hexdump_ascii(len=9): 77 6c 61 6e 5f 74 65 73 74 wlan_test client_cert - hexdump_ascii(len=10): 63 6c 69 65 6e 74 2e 70 65 6d client.pem private_key - hexdump_ascii(len=10): 63 6c 69 65 6e 74 2e 6b 65 79 client.key Priority group 0 id=0 ssid='eduroam' Authentication server 10.160.4.50:1812 EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portValid=0 EAPOL: External notification - portEnabled=1 EAPOL: SUPP_PAE entering state CONNECTING EAPOL: SUPP_BE entering state IDLE EAP: EAP entering state INITIALIZE EAP: EAP entering state IDLE EAPOL test timed out MPPE keys OK: 0 mismatch: 1 FAILURE Any help is appreciated. Thomas

3 6

Buy third party ssl-cert
by Benjamin Rechsteiner 26 Jul '15

26 Jul '15

Hi list, Can someone advise me, where can i buy a third party ssl-cert which is trusted by all windows clients? Cannot provide a self-sign ca-cert to the client ( bring you own device). Server: Debian 8 with Freeradius 2.2.5 and Windows Server 2008 R2 Best regards Beni -- Benjamin Rechsteiner Administrator benjamin.rechsteiner(a)automatic-server.com 0041 78 676 35 32

2 1

Re: AD Authentication using PAM_winbind.so succeeds, but FreeRadius 3.0.4 rejects with "Failed to Authenticate User"
by Josh Miller 26 Jul '15

26 Jul '15

Hi Alan, Really appreciate the reply. > The environment is as follows: > > -Fedora 22 > -Freeradius 3.0.4 > -Samba 4.2.2 >> I'd suggest using 3.0.9. I tried upgrading this morning to the version you suggested, and unfortunately there does not appear to be a RedHat/Fedora RPM from with 3.0.9, I did find one for 3.0.8 http://koji.fedoraproject.org/koji/packageinfo?packageID=298 Going step-by-step through the fabulous documentation found on freeradius.org: http://wiki.freeradius.org/guide/Red-Hat-FAQ#A-prebuilt-version-of-FreeRADI…'m-using,-how-do-I-build-one ? I attempted to begin the upgrade process to the latest freeradius-3.0.8-3.fc23.x86_64.rpm. and received a package dependency error: [root]# yum install freeradius-3.0.8-3.fc23.x86_64.rpm Error: nothing provides libcrypto.so.10(OPENSSL_1.0.2)(64bit) needed by freeradius-3.0.8-3.fc23.x86_64 However, the "libcrypto.so.10" is already installed. [root]# yum install libcrypto.so.10 Package openssl-libs-1:1.0.1k-11.fc22.i686 is already installed, skipping. Dependencies resolved. langpacks: enabled languages are [] Nothing to do. Complete! Am I missing something? > ---------------------- > #/etc/pam.d/radius > > auth required /usr/lib64/security/pam_winbind.so debug > ---------------------- >>Don't use PAM. It's not just horrible, it's designed to be used once by an application, and then never again. It will likely leak memory, cause performance issues, etc. >>I would suggest using the ntlm_auth program. It's documented, and it works. Fair enough. My understanding from the Google Authenticator documentation is that it requires the PAM libraries. The 2factor authentication piece is performed via /etc/pam.d/radius file by "forward_pass" attribute to the pam_google_authenticator.so. https://github.com/google/google-authenticator/blob/master/libpam/README > Standard NTLM via AD works very well, but utilizing the PAM module is > creating a whole new can of worms. >> Don't use PAM. It's almost impossible to understand. And almost impossible to debug. > My use case for PAM is 2 factor > authentication with Google Authenticator, but if there is a better way to > do this while still utilizing FreeRadius, then I am very interested. >> You can run Perl scripts directly from FreeRADIUS. That should help. Thanks for the suggestion, I've been researching this for the last hour. If Google TOTP requires PAM, is there anyway to reference a PAM function via pearl script. Or at least have it reference the /etc/pam.d/radiusd file for the Google auth portion of the authentication? The rlm_pearl documentation references chaning the Default Auth Type from PAM (in this case) to Pearl. > However, at this point I have not been unable to find another > authentication methodology for Google OTP without the PAM component. >> I don't see why PAM is necessary. Unless I am mistaken, I believe it is a requirement, reference the aforementioned Google Authenticator Githhub URL > Also attaching the, radius -XXX startup output separately. >> <sigh> Please use "radiusd -X". Not "-XXXXXXXXXXX". It doesn't help. >> Following directions is good. And the directions say "-X". My bad on that, the radiusd -X output is attached (was thinking more data is better). Lastly, would you mind sharing your opinion on what the most flexible flavor of Linux as far as FreeRadius is concerned (i.e.Ubuntu, Redhat, Centos etc)? Each one appears to have various anamolies. Thank you again.

3 9

Proxy CoA packet from network control to NAS(same as CoA server) configs in case of many many NASes.
by Sergey Komarov 26 Jul '15

26 Jul '15

Hello, Freeradius team and users community! First of all thanks to all creators of FreeRadius! It makes a lot of people happy ) I use FreeRadius 3.0.9 builded from a source on CentOS 6. Everything is fine. But I still can't find some details in documentation. So I need short comments to clarify. My pain. I have about 800 NASes in our network and all of them is home servers (CoA servers) (no redundancy due to small areas for each NAS). I do proxy CoA from my network control server (CoA client) to NASes that same time are CoA servers (Cisco WLCs) and configuration below works with small trick but as I expected. I named my home server pools same name as "IP" address and it helps me to avoid additional operations, it's good anyway. My question is if I have any chances to simplify configuration and avoid to write 800 home servers and home server pools (each pool still one server unfortunately)? I understand that templates technique may simplify home server sections little bit, but I still need 800 home servers and 800 home server pools? :( I've tried to use clients.conf and derive home servers from that section as announced in 3.0.7. It would simplify but I can't proxy to such kind of unnamed home server (or I can? This is what I didn't find in any docs too. Sorry). As I understand that NAS and CoA server can be same in case I add section in clients.conf.. If it possible to identify this CoA server somehow and send proxy packet to exact server (in my case IP same as NAS IP) it would be nice? 1. Could you please tell me if there is a way to send proxy packet to such unnamed home server (derived from clients) based on IP of my NAS? I've tried to use Packet-DST-IP-Address = "%{NAS-IP-Address}" together with Packet-Dst-Port = 1700 or without it, but seems it doesn't work. Freeradius in debug writes random port number and message like "home server 10.56.33.174 doesn't exists". Later I read in docs that I can't add name to such unnamed home servers so I can't use such home servers in combination with pools (for example) and than use Home-Server-Pool := "%{NAS-IP-Address}"... 2. Is there any way to use something in coa section like update control Home-Server := "%{NAS-IP-Address}" or some other options to proxy CoA packets to NAS/CoA server? Have I missed some important part? Sorry in advance if it is awkward moment. Thank you in advance for your help! Best Regards, Sergey Komaroff How it works now: ---sites enabled/сoa--------------------------------- server coa { recv-coa { suffix update control { # It works: Home-Server-Pool := "%{NAS-IP-Address}" # Tested to switch to this but it makes error home server X.X.X.X not found when home server derived from clients.conf # Packet-DST-IP-Address = "%{NAS-IP-Address}" # Packet-DST-Port = 1700 } # Insert your own policies here. ok } send-coa { # Sample module. ok } } ------------------------ clients.conf --------- client wlc_1 { ipaddr = 10.56.33.174 secret = secret nas_type = cisco coa_server = wlc1 } client wlc_2 { ipaddr = 10.56.33.190 secret = secret nas_type = cisco coa_server = wlc2 } client wlc_3 { ipaddr = 10.0.249.253 secret = secret nas_type = cisco coa_server = wlc3 } ...... ----------------proxy.conf------------------------ home_server wlc1 { type = coa ipaddr = 10.56.33.174 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server wlc2 { type = coa ipaddr = 10.0.249.253 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } home_server wlc3 { type = coa ipaddr = 10.56.33.190 port = 1700 secret = secret require_message_authenticator = no response_window = 20 zombie_period = 40 revive_interval = 120 status_check = none check_interval = 30 num_answers_to_alive = 3 coa { irt = 2 mrt = 16 mrc = 5 mrd = 30 } } ..... home_server_pool 10.56.33.174 { home_server = wlc1 } home_server_pool 10.0.249.253 { home_server = wlc2 } home_server_pool 10.56.33.190 { home_server = wlc3 } ..... -----------------------------------------------------------------------------------

3 16

3.0.9: linelog reply:Packet-Type
by Mohamed Lrhazi 26 Jul '15

26 Jul '15

I had this working in 3.0.8: Access-Request = "%S: %{reply:Packet-Type}: r=\"%{Module-Failure-Message}\" r2=\"%{reply:Reply-Message}\" u=%{User-Name} cis=%{Calling-Station-Id} cds=%{Called-Station-Id} pip=%{Packet-Src-IP-Address} nip=%{NAS-IP-Address} n=%{NAS-Identifier}" But in 3.0.9 It seems to give this error: Sun Jul 26 00:57:08 2015 : Debug: (52) linelog: EXPAND messages.%{%{reply:Packet-Type}:-default} Sun Jul 26 00:57:08 2015 : Debug: (52) linelog: --> messages.Access-Accept Sun Jul 26 00:57:08 2015 : Debug: (52) linelog: No such entry ".messages.Access-Accept" Am I doing something wrong? Any work around? Thanks, Mohamed.

1 1

Re: Delivery Status Notification (Failure)
by Josh Miller 25 Jul '15

25 Jul '15

Hi Alan, I'm the OP in this thread, so I should be subscribed, and I used my email client. Am I supposed to send the reply to freeradius-users(a)lists.freeradius.org ? I thought I could reply using the default reply-to address in the email that I received. On Sat, Jul 25, 2015 at 1:25 PM, Alan DeKok <aland(a)deployingradius.com> wrote: > You must subscribe to the list. You can't post messages through nabble. > > On Jul 25, 2015, at 4:18 PM, Josh Miller <jmills5901(a)gmail.com> wrote: > > > Hello, > > > > I'm trying to reply to this posting, and received the following message. > > > > I am the original owner to this thread, any idea's? > > ---------- Forwarded message ---------- > > From: Nabble <no-reply(a)nabble.com> > > Date: Sat, Jul 25, 2015 at 1:11 PM > > Subject: Delivery Status Notification (Failure) > > To: jmills5901(a)gmail.com > > > > > > Delivery to the following recipient failed permanently: > > > > ml-node+s1045715n5735555h15(a)n5.nabble.com > > > > Your email to ml-node+s1045715n5735555h15(a)n5.nabble.com has been > rejected because you are not allowed to post to > http://freeradius.1045715.n5.nabble.com/Re-AD-Authentication-using-PAM-winb… > . Please contact the owner about permissions or visit the Nabble Support > forum. > > > > ----- Original message ----- > > > > Return-Path: <jmills5901(a)gmail.com> > > X-Original-To: ml-node+s1045715n5735555h15(a)n5.nabble.com > > Delivered-To: ml-node+s1045715n5735555h15(a)n5.nabble.com > > Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com > [209.85.212.170]) > > by mwork.nabble.com (Postfix) with ESMTP id 7AE29246E8B0 > > for <ml-node+s1045715n5735555h15(a)n5.nabble.com>; Sat, 25 Jul > 2015 13:11:30 -0700 (PDT) > > Received: by wibud3 with SMTP id ud3so70203166wib.0 > > for <ml-node+s1045715n5735555h15(a)n5.nabble.com>; Sat, 25 Jul > 2015 13:11:17 -0700 (PDT) > > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > > d=gmail.com; s=20120113; > > > h=mime-version:in-reply-to:references:date:message-id:subject:from:to > > :content-type; > > bh=0yujVpE01UJehNx48aE+T86F8R8GZ3ntS/M056zUd/g=; > > > b=N1V8sR/7Wy3wVBiGZPuBh2FWq1S6uvN6aVrOSF/vyhFmBq2JdsEaYWI1Z2rR7CqQOS > > > NUGvbvI3iS441WbrgR1dx24XxsAlWpS10kUPWldZBCFOifZDoiYr26OFBFr2PN27dvQA > > > 45ahkPky/Z3Wackt5uw3AYa4O80hn57zpgo2SWp3XD5RPsu/3fhv9y+Ten0s0QjZbFai > > > CMN2igGYeqF2nTtaykkI9tYAbBXax/7vjMgavbvSVMXb4jwK1RK3u+SpzlpKi1831oEj > > > 0TBAFKV0YrhIRwzlzvVUlAtMLcMKeyF/d1lr+W/CXWtUR5Sih1LtVEU5qUKEPfr5ntyw > > bXvg== > > MIME-Version: 1.0 > > X-Received: by 10.194.187.51 with SMTP id > fp19mr37482458wjc.67.1437855077087; > > Sat, 25 Jul 2015 13:11:17 -0700 (PDT) > > Received: by 10.28.6.193 with HTTP; Sat, 25 Jul 2015 13:11:16 -0700 (PDT) > > In-Reply-To: <188E15CE-F879-4B4E-8E8D-5B2620C8B2A7(a)deployingradius.com> > > References: < > CALcJ2UpnOtf4GF--+aR82pmJ-_p4GsZPAuG2tW5TZLvftH85cw(a)mail.gmail.com> > > <188E15CE-F879-4B4E-8E8D-5B2620C8B2A7(a)deployingradius.com> > > Date: Sat, 25 Jul 2015 13:11:16 -0700 > > Message-ID: <CALcJ2Ur_WJewtKOpnm4krYC2kDwUmzo= > pusGCqPF0yxacdc-9g(a)mail.gmail.com> > > Subject: Re: AD Authentication using PAM_winbind.so succeeds, but > FreeRadius > > 3.0.4 rejects with "Failed to Authenticate User" > > From: Josh Miller <jmills5901(a)gmail.com> > > To: "Alan DeKok-2 [via FreeRADIUS]" < > ml-node+s1045715n5735555h15(a)n5.nabble.com> > > Content-Type: multipart/mixed; boundary=047d7bb03dce1c3453051bb8b92a > > > > --047d7bb03dce1c3453051bb8b92a > > Content-Type: multipart/alternative; > boundary=047d7bb03dce1c344d051bb8b928 > > > > --047d7bb03dce1c344d051bb8b928 > > Content-Type: text/plain; charset=UTF-8 > > > > Hi Alan, > > > > Really appreciate the reply. > > > > > > > > > > > The environment is as follows: > > > > > > > > -Fedora 22 > > > > -Freeradius 3.0.4 > > > > -Samba 4.2.2 > > > > > > I'd suggest using 3.0.9. > > > > > > > > I tried upgrading this morning to the version you suggested, and > > unfortunately there does not appear to be a RedHat/Fedora RPM from with > > 3.0.9, I did find one for 3.0.8 > > > > http://koji.fedoraproject.org/koji/packageinfo?packageID=298 > > > > Going step-by-step through the fabulous documentation found on > > freeradius.org: > > > > > http://wiki.freeradius.org/guide/Red-Hat-FAQ#A-prebuilt-version-of-FreeRADI…'m-using,-how-do-I-build-one > > ? > > > > I attempted to begin the upgrade process to the latest > > freeradius-3.0.8-3.fc23.x86_64.rpm. and received a package dependency > error: > > > > > > [root]# yum install freeradius-3.0.8-3.fc23.x86_64.rpm > > Error: nothing provides libcrypto.so.10(OPENSSL_1.0.2)(64bit) needed by > > freeradius-3.0.8-3.fc23.x86_64 > > > > > > > > However, the "libcrypto.so.10" is already installed. > > > > > > > > [root]# yum install libcrypto.so.10 > > Package openssl-libs-1:1.0.1k-11.fc22.i686 is already installed, > skipping. > > Dependencies resolved. > > langpacks: enabled languages are [] > > Nothing to do. > > Complete! > > > > > > > > Am I missing something? > > > > > > > > > ---------------------- > > > > #/etc/pam.d/radius > > > > > > > > auth required /usr/lib64/security/pam_winbind.so debug > > > > ---------------------- > > > > > > Don't use PAM. It's not just horrible, it's designed to be used once > by > > > an application, and then never again. It will likely leak memory, > cause > > > performance issues, etc. > > > > I would suggest using the ntlm_auth program. It's documented, and it > > > works. > > > > > > > Fair enough. > > > > My understanding from the Google Authenticator documentation is that it > > requires the PAM libraries. The 2factor authentication piece is > performed > > via /etc/pam.d/radius file by "forward_pass" attribute to the > > pam_google_authenticator.so. > > https://github.com/google/google-authenticator/blob/master/libpam/README > > > > > > > > Standard NTLM via AD works very well, but utilizing the PAM module is > > > > creating a whole new can of worms. > > > > > > Don't use PAM. It's almost impossible to understand. And almost > > > impossible to debug. > > > > > > > > > > > My use case for PAM is 2 factor > > > > authentication with Google Authenticator, but if there is a better > way > > > to > > > > do this while still utilizing FreeRadius, then I am very interested. > > > > > > You can run Perl scripts directly from FreeRADIUS. That should help. > > > > > > > > Thanks for the suggestion, I've been researching this for the last hour. > > If Google TOTP requires PAM, is there anyway to reference a PAM function > > via pearl script. Or at least have it reference the /etc/pam.d/radiusd > file > > for the Google auth portion of the authentication? > > > > The rlm_pearl documentation references chaning the Default Auth Type from > > PAM (in this case) to Pearl. > > > > > > > > However, at this point I have not been unable to find another > > > > authentication methodology for Google OTP without the PAM component. > > > > > > I don't see why PAM is necessary. > > > > > > > > > Unless I am mistaken, I believe it is a requirement, reference the > > aforementioned Google Authenticator Githhub URL > > > > > > > > > > > Also attaching the, radius -XXX startup output separately. > > > > > > <sigh> Please use "radiusd -X". Not "-XXXXXXXXXXX". It doesn't > help. > > > > > > Following directions is good. And the directions say "-X". > > > > > > Alan DeKok. > > > > > > > > My bad on that, the radiusd -X output is attached (was thinking more data > > is better). > > > > Lastly, in your opinion, what is the most flexible flavor of Linux as far > > as FreeRadius is concerned (i.e.Ubuntu, Redhat, Centos etc)? > > > > Thank you again. > > > > --047d7bb03dce1c344d051bb8b928 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > > <div dir=3D"ltr">Hi Alan,<div><br></div><div>Really appreciate the > reply.</= > > div><div>=C2=A0<br></div><div class=3D"gmail_extra"><div > class=3D"gmail_quo= > > te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 > .8ex;border-lef= > > t:1px #ccc solid;padding-left:1ex"><span class=3D""><br>> The > environmen= > > t is as follows: > > <br>>=20 > > <br>> -Fedora 22 > > <br>> -Freeradius 3.0.4 > > <br>> -Samba 4.2.2 > > <br><br></span>=C2=A0 I'd suggest using 3.0.9. > > <br><span class=3D""><br></span></blockquote><div><br></div><div>I tried > up= > > grading this morning to the version you suggested, and unfortunately > there = > > does not appear to be a RedHat/Fedora RPM from with 3.0.9, =C2=A0I did > find= > > one for 3.0.8</div><div><br></div><div><a href=3D" > http://koji.fedoraprojec= > > t.org/koji/packageinfo?packageID=3D298"> > http://koji.fedoraproject.org/koji/= > > packageinfo?packageID=3D298</a><br></div><div><br></div><div>Going > step-by-= > > step through the fabulous documentation found on <a href=3D" > http://freeradi= > > us.org">freeradius.org</a>:<br></div><div><br></div><div><a > href=3D"http://= > > > wiki.freeradius.org/guide/Red-Hat-FAQ#A-prebuilt-version-of-FreeRADIUS-in-t= > > > he-version-I-need-is-not-available-for-the-distribution-I'm-using,-how-= > > do-I-build-one"> > http://wiki.freeradius.org/guide/Red-Hat-FAQ#A-prebuilt-ver= > > > sion-of-FreeRADIUS-in-the-version-I-need-is-not-available-for-the-distribut= > > > ion-I'm-using,-how-do-I-build-one</a>?<br></div><div><br></div><div>I a= > > ttempted to begin the upgrade process to the latest > freeradius-3.0.8-3.fc23= > > .x86_64.rpm. and received a package dependency > error:<br></div><div><br></d= > > iv><div><br></div><div><div>[root]# yum install > freeradius-3.0.8-3.fc23.x86= > > _64.rpm</div><div>Error: nothing provides > libcrypto.so.10(OPENSSL_1.0.2)(64= > > bit) needed by > freeradius-3.0.8-3.fc23.x86_64<br></div></div><div><br></div= > > ><div><br></div><div><br></div><div>However, the > "libcrypto.so.10&quot= > > ; is already > installed.</div><div><div><br></div><div><br></div><div><br></= > > div><div>[root]# yum install libcrypto.so.10</div><div>Package > openssl-libs= > > -1:1.0.1k-11.fc22.i686 is already installed, > skipping.<br></div><div>Depend= > > encies resolved.</div><div>langpacks: enabled languages are > []</div><div>No= > > thing to > do.</div><div>Complete!</div></div><div><br></div><div><br></div><= > > div><br></div><div>Am I missing > something?</div><div><br></div><div><br></d= > > iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 > 0 .= > > 8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> > ----= > > ------------------ > > <br>> #/etc/pam.d/radius > > <br>>=20 > > <br>> auth required /usr/lib64/security/pam_winbind.so debug > > <br>> ---------------------- > > <br><br></span>Don't use PAM.=C2=A0 It's not just horrible, > it'= > > s designed to be used once by an application, and then never > again.=C2=A0 I= > > t will likely leak memory, cause performance issues, etc. > =C2=A0</blockquot= > > e><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 > .8ex;border-left:= > > 1px #ccc solid;padding-left:1ex">I would suggest using the ntlm_auth > progra= > > m.=C2=A0 It's documented, and it > works.=C2=A0<br></blockquote><div>=C2= > > =A0</div><div>Fair enough. =C2=A0=C2=A0</div><div><br></div><div>My > underst= > > anding from the Google Authenticator documentation is that it requires > the = > > PAM libraries.=C2=A0 The 2factor authentication piece is performed via > /etc= > > /pam.d/radius file by "forward_pass" attribute to the > pam_google_= > > authenticator.so. =C2=A0<a href=3D" > https://github.com/google/google-authent= > > icator/blob/master/libpam/README"> > https://github.com/google/google-authenti= > > cator/blob/master/libpam/README</a></div><div>=C2=A0</div><blockquote > class= > > =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padd= > > ing-left:1ex"><span class=3D"">> Standard NTLM via AD works very > well, b= > > ut utilizing the PAM module is > > <br>> creating a whole new can of worms. > > <br><br></span>=C2=A0 Don't use PAM.=C2=A0 It's almost > impossible t= > > o understand.=C2=A0 And almost impossible to > debug.=C2=A0</blockquote><bloc= > > kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px > #cc= > > c solid;padding-left:1ex"> > > <br><span class=3D""><br>> =C2=A0My use case for PAM is 2 factor > > <br>> authentication with Google Authenticator, but if there is a > better= > > way to > > <br>> do this while still utilizing FreeRadius, then I am very > intereste= > > d. > > <br><br></span>=C2=A0 You can run Perl scripts directly from > FreeRADIUS.=C2= > > =A0 That should help. > > <br><span class=3D""><br></span></blockquote><div><br></div><div>Thanks > for= > > the suggestion, I've been researching this for the last hour.=C2=A0 > If= > > Google TOTP requires PAM, is there anyway to reference a PAM function > via = > > pearl script. Or at least have it reference the /etc/pam.d/radiusd file > for= > > the Google auth portion of the authentication? > =C2=A0=C2=A0</div><div><br>= > > </div><div>The rlm_pearl documentation references chaning the Default > Auth = > > Type from PAM (in this case) to > Pearl.<br></div><div>=C2=A0</div><blockquot= > > e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc > sol= > > id;padding-left:1ex"><span class=3D"">> However, at this point I have > no= > > t been unable to find another > > <br>> authentication methodology for Google OTP without the PAM > componen= > > t. > > <br><br></span>=C2=A0 I don't see why PAM is necessary. > > <br></blockquote><div><br></div><div><br></div><div>Unless I am > mistaken, I= > > believe it is a requirement, reference the aforementioned Google > Authentic= > > ator Githhub URL</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" > st= > > yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"><span= > > class=3D""><br>> Also attaching the, radius -XXX startup output > separat= > > ely. > > <br><br></span>=C2=A0 <sigh> =C2=A0Please use "radiusd > -X".= > > =C2=A0 Not "-XXXXXXXXXXX".=C2=A0 It doesn't help. > > <br><br>=C2=A0 Following directions is good.=C2=A0 And the directions > say &= > > quot;-X". > > <br><br>=C2=A0 Alan DeKok. > > <br><br></blockquote><div><br></div><div>My bad on that, the radiusd -X > out= > > put is attached (was thinking more data is better). > =C2=A0</div><div><br></= > > div><div>Lastly, in your opinion, what is the most flexible flavor of > Linux= > > as far as FreeRadius is concerned (i.e.Ubuntu, Redhat, Centos etc)? > =C2=A0= > > </div><div><br></div><div>Thank you > again.</div><div><br></div><div><br></d= > > iv></div></div></div> > > > > --047d7bb03dce1c344d051bb8b928-- > > --047d7bb03dce1c3453051bb8b92a > > Content-Type: text/plain; charset=US-ASCII; name="radiusd -X output.txt" > > Content-Disposition: attachment; filename="radiusd -X output.txt" > > Content-Transfer-Encoding: base64 > > X-Attachment-Id: f_icjg98jn0 > > > > > W3Jvb3RAaGxzZnJlZXJhZGl1czAxIH5dIyByYWRpdXNkIC1YDQpyYWRpdXNkOiBGcmVlUkFESVVT > > > IFZlcnNpb24gMy4wLjQsIGZvciBob3N0IHg4Nl82NC1yZWRoYXQtbGludXgtZ251LCBidWlsdCBv > > > biBGZWIgMTMgMjAxNSBhdCAxMjoxNToxMA0KQ29weXJpZ2h0IChDKSAxOTk5LTIwMTQgVGhlIEZy > > > ZWVSQURJVVMgc2VydmVyIHByb2plY3QgYW5kIGNvbnRyaWJ1dG9ycw0KVGhlcmUgaXMgTk8gd2Fy > > > cmFudHk7IG5vdCBldmVuIGZvciBNRVJDSEFOVEFCSUxJVFkgb3IgRklUTkVTUyBGT1IgQQ0KUEFS > > > VElDVUxBUiBQVVJQT1NFDQpZb3UgbWF5IHJlZGlzdHJpYnV0ZSBjb3BpZXMgb2YgRnJlZVJBRElV > > > UyB1bmRlciB0aGUgdGVybXMgb2YgdGhlDQpHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZQ0KRm9y > > > IG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgdGhlc2UgbWF0dGVycywgc2VlIHRoZSBmaWxlIG5hbWVk > > > IENPUFlSSUdIVA0KU3RhcnRpbmcgLSByZWFkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZXMgLi4uDQpp > > > bmNsdWRpbmcgZGljdGlvbmFyeSBmaWxlIC91c3Ivc2hhcmUvZnJlZXJhZGl1cy9kaWN0aW9uYXJ5 > > > DQppbmNsdWRpbmcgZGljdGlvbmFyeSBmaWxlIC91c3Ivc2hhcmUvZnJlZXJhZGl1cy9kaWN0aW9u > > > YXJ5LmRoY3ANCmluY2x1ZGluZyBkaWN0aW9uYXJ5IGZpbGUgL3Vzci9zaGFyZS9mcmVlcmFkaXVz > > > L2RpY3Rpb25hcnkudnFwDQppbmNsdWRpbmcgZGljdGlvbmFyeSBmaWxlIC9ldGMvcmFkZGIvZGlj > > > dGlvbmFyeQ0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL3JhZGl1c2Qu > > > Y29uZg0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL3Byb3h5LmNvbmYN > > > CmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9jbGllbnRzLmNvbmYNCmlu > > > Y2x1ZGluZyBmaWxlcyBpbiBkaXJlY3RvcnkgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvDQppbmNs > > > dWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2Fsd2F5cw0K > > > aW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9hdHRy > > > X2ZpbHRlcg0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5h > > > YmxlZC9jYWNoZV9lYXANCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9t > > > b2RzLWVuYWJsZWQvY2hhcA0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRi > > > L21vZHMtZW5hYmxlZC9kZXRhaWwNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9y > > > YWRkYi9tb2RzLWVuYWJsZWQvZGV0YWlsLmxvZw0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmls > > > ZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9kaGNwDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBm > > > aWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2RpZ2VzdA0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRp > > > b24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9keW5hbWljX2NsaWVudHMNCmluY2x1ZGlu > > > ZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZWFwDQppbmNsdWRp > > > bmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2VjaG8NCmluY2x1 > > > ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZXhlYw0KaW5j > > > bHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9leHBpcmF0 > > > aW9uDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVk > > > L2V4cHINCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJs > > > ZWQvZmlsZXMNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVu > > > YWJsZWQvbGluZWxvZw0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21v > > > ZHMtZW5hYmxlZC9sb2dpbnRpbWUNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9y > > > YWRkYi9tb2RzLWVuYWJsZWQvbXNjaGFwDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9l > > > dGMvcmFkZGIvbW9kcy1lbmFibGVkL250bG1fYXV0aA0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24g > > > ZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9wYXANCmluY2x1ZGluZyBjb25maWd1cmF0aW9u > > > IGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvcGFzc3dkDQppbmNsdWRpbmcgY29uZmlndXJh > > > dGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL3ByZXByb2Nlc3MNCmluY2x1ZGluZyBj > > > b25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvcmFkdXRtcA0KaW5jbHVk > > > aW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9yZWFsbQ0KaW5j > > > bHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9yZXBsaWNh > > > dGUNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQv > > > c29oDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVk > > > L3NyYWR1dG1wDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvbW9kcy1l > > > bmFibGVkL3VuaXgNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRkYi9tb2Rz > > > LWVuYWJsZWQvdW5wYWNrDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIv > > > bW9kcy1lbmFibGVkL3V0ZjgNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0Yy9yYWRk > > > Yi9tb2RzLWVuYWJsZWQvcGFtDQppbmNsdWRpbmcgZmlsZXMgaW4gZGlyZWN0b3J5IC9ldGMvcmFk > > > ZGIvcG9saWN5LmQvDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFkZGIvcG9s > > > aWN5LmQvYWNjb3VudGluZw0KaW5jbHVkaW5nIGNvbmZpZ3VyYXRpb24gZmlsZSAvZXRjL3JhZGRi > > > L3BvbGljeS5kL2Nhbm9uaWNhbGl6YXRpb24NCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUg > > > L2V0Yy9yYWRkYi9wb2xpY3kuZC9jb250cm9sDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxl > > > IC9ldGMvcmFkZGIvcG9saWN5LmQvY3VpDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9l > > > dGMvcmFkZGIvcG9saWN5LmQvZGVidWcNCmluY2x1ZGluZyBjb25maWd1cmF0aW9uIGZpbGUgL2V0 > > > Yy9yYWRkYi9wb2xpY3kuZC9kaGNwDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMv > > > cmFkZGIvcG9saWN5LmQvZWFwDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFk > > > ZGIvcG9saWN5LmQvZmlsdGVyDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9ldGMvcmFk > > > ZGIvcG9saWN5LmQvb3BlcmF0b3ItbmFtZQ0KaW5jbHVkaW5nIGZpbGVzIGluIGRpcmVjdG9yeSAv > > > ZXRjL3JhZGRiL3NpdGVzLWVuYWJsZWQvDQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBmaWxlIC9l > > > dGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9kZWZhdWx0DQppbmNsdWRpbmcgY29uZmlndXJhdGlvbiBm > > > aWxlIC9ldGMvcmFkZGIvc2l0ZXMtZW5hYmxlZC9pbm5lci10dW5uZWwNCm1haW4gew0KIHNlY3Vy > > > aXR5IHsNCiAgICAgICAgYWxsb3dfY29yZV9kdW1wcyA9IG5vDQogfQ0KfQ0KbWFpbiB7DQogICAg > > > ICAgIG5hbWUgPSAicmFkaXVzZCINCiAgICAgICAgcHJlZml4ID0gIi91c3IiDQogICAgICAgIGxv > > > Y2Fsc3RhdGVkaXIgPSAiL3ZhciINCiAgICAgICAgc2JpbmRpciA9ICIvdXNyL3NiaW4iDQogICAg > > > ICAgIGxvZ2RpciA9ICIvdmFyL2xvZy9yYWRpdXMiDQogICAgICAgIHJ1bl9kaXIgPSAiL3Zhci9y > > > dW4vcmFkaXVzZCINCiAgICAgICAgbGliZGlyID0gIi91c3IvbGliNjQvZnJlZXJhZGl1cyINCiAg > > > ICAgICAgcmFkYWNjdGRpciA9ICIvdmFyL2xvZy9yYWRpdXMvcmFkYWNjdCINCiAgICAgICAgaG9z > > > dG5hbWVfbG9va3VwcyA9IG5vDQogICAgICAgIG1heF9yZXF1ZXN0X3RpbWUgPSAzMA0KICAgICAg > > > ICBjbGVhbnVwX2RlbGF5ID0gNQ0KICAgICAgICBtYXhfcmVxdWVzdHMgPSAxMDI0DQogICAgICAg > > > IHBpZGZpbGUgPSAiL3Zhci9ydW4vcmFkaXVzZC9yYWRpdXNkLnBpZCINCiAgICAgICAgY2hlY2ty > > > YWQgPSAiL3Vzci9zYmluL2NoZWNrcmFkIg0KICAgICAgICBkZWJ1Z19sZXZlbCA9IDANCiAgICAg > > > ICAgcHJveHlfcmVxdWVzdHMgPSB5ZXMNCiBsb2cgew0KICAgICAgICBzdHJpcHBlZF9uYW1lcyA9 > > > IG5vDQogICAgICAgIGF1dGggPSB5ZXMNCiAgICAgICAgYXV0aF9iYWRwYXNzID0geWVzDQogICAg > > > ICAgIGF1dGhfZ29vZHBhc3MgPSB5ZXMNCiAgICAgICAgY29sb3VyaXNlID0geWVzDQogICAgICAg > > > IG1zZ19kZW5pZWQgPSAiWW91IGFyZSBhbHJlYWR5IGxvZ2dlZCBpbiAtIGFjY2VzcyBkZW5pZWQi > > > DQogfQ0KIHNlY3VyaXR5IHsNCiAgICAgICAgbWF4X2F0dHJpYnV0ZXMgPSAyMDANCiAgICAgICAg > > > cmVqZWN0X2RlbGF5ID0gMQ0KICAgICAgICBzdGF0dXNfc2VydmVyID0geWVzDQogfQ0KfQ0KcmFk > > > aXVzZDogIyMjIyBMb2FkaW5nIFJlYWxtcyBhbmQgSG9tZSBTZXJ2ZXJzICMjIyMNCiBwcm94eSBz > > > ZXJ2ZXIgew0KICAgICAgICByZXRyeV9kZWxheSA9IDUNCiAgICAgICAgcmV0cnlfY291bnQgPSAz > > > DQogICAgICAgIGRlZmF1bHRfZmFsbGJhY2sgPSBubw0KICAgICAgICBkZWFkX3RpbWUgPSAxMjAN > > > CiAgICAgICAgd2FrZV9hbGxfaWZfYWxsX2RlYWQgPSBubw0KIH0NCiBob21lX3NlcnZlciBsb2Nh > > > bGhvc3Qgew0KICAgICAgICBpcGFkZHIgPSAxMjcuMC4wLjENCiAgICAgICAgcG9ydCA9IDE4MTIN > > > CiAgICAgICAgdHlwZSA9ICJhdXRoIg0KICAgICAgICBzZWNyZXQgPSA8PDwgc2VjcmV0ID4+Pg0K > > > ICAgICAgICByZXNwb25zZV93aW5kb3cgPSAyMC4wMDAwMDANCiAgICAgICAgcmVzcG9uc2VfdGlt > > > ZW91dHMgPSAxDQogICAgICAgIG1heF9vdXRzdGFuZGluZyA9IDY1NTM2DQogICAgICAgIHpvbWJp > > > ZV9wZXJpb2QgPSA0MA0KICAgICAgICBzdGF0dXNfY2hlY2sgPSAic3RhdHVzLXNlcnZlciINCiAg > > > ICAgICAgcGluZ19pbnRlcnZhbCA9IDMwDQogICAgICAgIGNoZWNrX2ludGVydmFsID0gMzANCiAg > > > ICAgICAgY2hlY2tfdGltZW91dCA9IDQNCiAgICAgICAgbnVtX2Fuc3dlcnNfdG9fYWxpdmUgPSAz > > > DQogICAgICAgIHJldml2ZV9pbnRlcnZhbCA9IDEyMA0KICBjb2Egew0KICAgICAgICBpcnQgPSAy > > > DQogICAgICAgIG1ydCA9IDE2DQogICAgICAgIG1yYyA9IDUNCiAgICAgICAgbXJkID0gMzANCiAg > > > fQ0KICBsaW1pdCB7DQogICAgICAgIG1heF9jb25uZWN0aW9ucyA9IDE2DQogICAgICAgIG1heF9y > > > ZXF1ZXN0cyA9IDANCiAgICAgICAgbGlmZXRpbWUgPSAwDQogICAgICAgIGlkbGVfdGltZW91dCA9 > > > IDANCiAgfQ0KIH0NCiBob21lX3NlcnZlcl9wb29sIG15X2F1dGhfZmFpbG92ZXIgew0KICAgICAg > > > ICB0eXBlID0gZmFpbC1vdmVyDQogICAgICAgIGhvbWVfc2VydmVyID0gbG9jYWxob3N0DQogfQ0K > > > IHJlYWxtIGV4YW1wbGUuY29tIHsNCiAgICAgICAgYXV0aF9wb29sID0gbXlfYXV0aF9mYWlsb3Zl > > > cg0KIH0NCiByZWFsbSBMT0NBTCB7DQogfQ0KcmFkaXVzZDogIyMjIyBMb2FkaW5nIENsaWVudHMg > > > IyMjIw0KIGNsaWVudCBsb2NhbGhvc3Qgew0KICAgICAgICBpcGFkZHIgPSAxMjcuMC4wLjENCiAg > > > ICAgICAgcmVxdWlyZV9tZXNzYWdlX2F1dGhlbnRpY2F0b3IgPSBubw0KICAgICAgICBzZWNyZXQg > > > PSA8PDwgc2VjcmV0ID4+Pg0KICAgICAgICBuYXNfdHlwZSA9ICJvdGhlciINCiAgICAgICAgcHJv > > > dG8gPSAiKiINCiAgbGltaXQgew0KICAgICAgICBtYXhfY29ubmVjdGlvbnMgPSAxNg0KICAgICAg > > > ICBsaWZldGltZSA9IDANCiAgICAgICAgaWRsZV90aW1lb3V0ID0gMzANCiAgfQ0KIH0NCiBjbGll > > > bnQgMTAuMTAxLjMuMSB7DQogICAgICAgIGlwYWRkciA9IDEwLjEwMS4zLjENCiAgICAgICAgcmVx > > > dWlyZV9tZXNzYWdlX2F1dGhlbnRpY2F0b3IgPSBubw0KICAgICAgICBzZWNyZXQgPSA8PDwgc2Vj > > > cmV0ID4+Pg0KICBsaW1pdCB7DQogICAgICAgIG1heF9jb25uZWN0aW9ucyA9IDE2DQogICAgICAg > > > IGxpZmV0aW1lID0gMA0KICAgICAgICBpZGxlX3RpbWVvdXQgPSAzMA0KICB9DQogfQ0KIGNsaWVu > > > dCAxMC4xMDEuMC4wLzE2IHsNCiAgICAgICAgcmVxdWlyZV9tZXNzYWdlX2F1dGhlbnRpY2F0b3Ig > > > PSBubw0KICAgICAgICBzZWNyZXQgPSA8PDwgc2VjcmV0ID4+Pg0KICAgICAgICBzaG9ydG5hbWUg > > > PSAibmV0d29yazEiDQogIGxpbWl0IHsNCiAgICAgICAgbWF4X2Nvbm5lY3Rpb25zID0gMTYNCiAg > > > ICAgICAgbGlmZXRpbWUgPSAwDQogICAgICAgIGlkbGVfdGltZW91dCA9IDMwDQogIH0NCiB9DQpO > > > byAnaXBhZGRyJyBvciAnaXB2NGFkZHInIG9yICdpcHY2YWRkcicgZmllbGQgZm91bmQgaW4gY2xp > > > ZW50IDEwLjEwMS4wLjAvMTYuICBQbGVhc2UgZml4IHlvdXIgY29uZmlndXJhdGlvbg0KU3VwcG9y > > > dCBmb3Igb2xkLXN0eWxlIGNsaWVudHMgd2lsbCBiZSByZW1vdmVkIGluIGEgZnV0dXJlIHJlbGVh > > > c2UNCnJhZGl1c2Q6ICMjIyMgSW5zdGFudGlhdGluZyBtb2R1bGVzICMjIyMNCiBpbnN0YW50aWF0 > > > ZSB7DQogfQ0KIG1vZHVsZXMgew0KICAjIExvYWRlZCBtb2R1bGUgcmxtX2Fsd2F5cw0KICAjIElu > > > c3RhbnRpYXRpbmcgbW9kdWxlICJyZWplY3QiIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5h > > > YmxlZC9hbHdheXMNCiAgYWx3YXlzIHJlamVjdCB7DQogICAgICAgIHJjb2RlID0gInJlamVjdCIN > > > CiAgICAgICAgc2ltdWxjb3VudCA9IDANCiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3Rh > > > bnRpYXRpbmcgbW9kdWxlICJmYWlsIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQv > > > YWx3YXlzDQogIGFsd2F5cyBmYWlsIHsNCiAgICAgICAgcmNvZGUgPSAiZmFpbCINCiAgICAgICAg > > > c2ltdWxjb3VudCA9IDANCiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcg > > > bW9kdWxlICJvayIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2Fsd2F5cw0KICBh > > > bHdheXMgb2sgew0KICAgICAgICByY29kZSA9ICJvayINCiAgICAgICAgc2ltdWxjb3VudCA9IDAN > > > CiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJoYW5kbGVk > > > IiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvYWx3YXlzDQogIGFsd2F5cyBoYW5k > > > bGVkIHsNCiAgICAgICAgcmNvZGUgPSAiaGFuZGxlZCINCiAgICAgICAgc2ltdWxjb3VudCA9IDAN > > > CiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJpbnZhbGlk > > > IiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvYWx3YXlzDQogIGFsd2F5cyBpbnZh > > > bGlkIHsNCiAgICAgICAgcmNvZGUgPSAiaW52YWxpZCINCiAgICAgICAgc2ltdWxjb3VudCA9IDAN > > > CiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJ1c2VybG9j > > > ayIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2Fsd2F5cw0KICBhbHdheXMgdXNl > > > cmxvY2sgew0KICAgICAgICByY29kZSA9ICJ1c2VybG9jayINCiAgICAgICAgc2ltdWxjb3VudCA9 > > > IDANCiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJub3Rm > > > b3VuZCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2Fsd2F5cw0KICBhbHdheXMg > > > bm90Zm91bmQgew0KICAgICAgICByY29kZSA9ICJub3Rmb3VuZCINCiAgICAgICAgc2ltdWxjb3Vu > > > dCA9IDANCiAgICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJu > > > b29wIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvYWx3YXlzDQogIGFsd2F5cyBu > > > b29wIHsNCiAgICAgICAgcmNvZGUgPSAibm9vcCINCiAgICAgICAgc2ltdWxjb3VudCA9IDANCiAg > > > ICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJ1cGRhdGVkIiBm > > > cm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvYWx3YXlzDQogIGFsd2F5cyB1cGRhdGVk > > > IHsNCiAgICAgICAgcmNvZGUgPSAidXBkYXRlZCINCiAgICAgICAgc2ltdWxjb3VudCA9IDANCiAg > > > ICAgICAgbXBwID0gbm8NCiAgfQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX2F0dHJfZmlsdGVyDQog > > > ICMgSW5zdGFudGlhdGluZyBtb2R1bGUgImF0dHJfZmlsdGVyLnBvc3QtcHJveHkiIGZyb20gZmls > > > ZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9hdHRyX2ZpbHRlcg0KICBhdHRyX2ZpbHRlciBhdHRy > > > X2ZpbHRlci5wb3N0LXByb3h5IHsNCiAgICAgICAgZmlsZW5hbWUgPSAiL2V0Yy9yYWRkYi9tb2Rz > > > LWNvbmZpZy9hdHRyX2ZpbHRlci9wb3N0LXByb3h5Ig0KICAgICAgICBrZXkgPSAiJXtSZWFsbX0i > > > DQogICAgICAgIHJlbGF4ZWQgPSBubw0KICB9DQpyZWFkaW5nIHBhaXJsaXN0IGZpbGUgL2V0Yy9y > > > YWRkYi9tb2RzLWNvbmZpZy9hdHRyX2ZpbHRlci9wb3N0LXByb3h5DQogICMgSW5zdGFudGlhdGlu > > > ZyBtb2R1bGUgImF0dHJfZmlsdGVyLnByZS1wcm94eSIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9k > > > cy1lbmFibGVkL2F0dHJfZmlsdGVyDQogIGF0dHJfZmlsdGVyIGF0dHJfZmlsdGVyLnByZS1wcm94 > > > eSB7DQogICAgICAgIGZpbGVuYW1lID0gIi9ldGMvcmFkZGIvbW9kcy1jb25maWcvYXR0cl9maWx0 > > > ZXIvcHJlLXByb3h5Ig0KICAgICAgICBrZXkgPSAiJXtSZWFsbX0iDQogICAgICAgIHJlbGF4ZWQg > > > PSBubw0KICB9DQpyZWFkaW5nIHBhaXJsaXN0IGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9h > > > dHRyX2ZpbHRlci9wcmUtcHJveHkNCiAgIyBJbnN0YW50aWF0aW5nIG1vZHVsZSAiYXR0cl9maWx0 > > > ZXIuYWNjZXNzX3JlamVjdCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2F0dHJf > > > ZmlsdGVyDQogIGF0dHJfZmlsdGVyIGF0dHJfZmlsdGVyLmFjY2Vzc19yZWplY3Qgew0KICAgICAg > > > ICBmaWxlbmFtZSA9ICIvZXRjL3JhZGRiL21vZHMtY29uZmlnL2F0dHJfZmlsdGVyL2FjY2Vzc19y > > > ZWplY3QiDQogICAgICAgIGtleSA9ICIle1VzZXItTmFtZX0iDQogICAgICAgIHJlbGF4ZWQgPSBu > > > bw0KICB9DQpyZWFkaW5nIHBhaXJsaXN0IGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9hdHRy > > > X2ZpbHRlci9hY2Nlc3NfcmVqZWN0DQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgImF0dHJfZmls > > > dGVyLmFjY2Vzc19jaGFsbGVuZ2UiIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9h > > > dHRyX2ZpbHRlcg0KICBhdHRyX2ZpbHRlciBhdHRyX2ZpbHRlci5hY2Nlc3NfY2hhbGxlbmdlIHsN > > > CiAgICAgICAgZmlsZW5hbWUgPSAiL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9hdHRyX2ZpbHRlci9h > > > Y2Nlc3NfY2hhbGxlbmdlIg0KICAgICAgICBrZXkgPSAiJXtVc2VyLU5hbWV9Ig0KICAgICAgICBy > > > ZWxheGVkID0gbm8NCiAgfQ0KcmVhZGluZyBwYWlybGlzdCBmaWxlIC9ldGMvcmFkZGIvbW9kcy1j > > > b25maWcvYXR0cl9maWx0ZXIvYWNjZXNzX2NoYWxsZW5nZQ0KICAjIEluc3RhbnRpYXRpbmcgbW9k > > > dWxlICJhdHRyX2ZpbHRlci5hY2NvdW50aW5nX3Jlc3BvbnNlIiBmcm9tIGZpbGUgL2V0Yy9yYWRk > > > Yi9tb2RzLWVuYWJsZWQvYXR0cl9maWx0ZXINCiAgYXR0cl9maWx0ZXIgYXR0cl9maWx0ZXIuYWNj > > > b3VudGluZ19yZXNwb25zZSB7DQogICAgICAgIGZpbGVuYW1lID0gIi9ldGMvcmFkZGIvbW9kcy1j > > > b25maWcvYXR0cl9maWx0ZXIvYWNjb3VudGluZ19yZXNwb25zZSINCiAgICAgICAga2V5ID0gIiV7 > > > VXNlci1OYW1lfSINCiAgICAgICAgcmVsYXhlZCA9IG5vDQogIH0NCnJlYWRpbmcgcGFpcmxpc3Qg > > > ZmlsZSAvZXRjL3JhZGRiL21vZHMtY29uZmlnL2F0dHJfZmlsdGVyL2FjY291bnRpbmdfcmVzcG9u > > > c2UNCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV9jYWNoZQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxl > > > ICJjYWNoZV9lYXAiIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9jYWNoZV9lYXAN > > > CiAgY2FjaGUgY2FjaGVfZWFwIHsNCiAgICAgICAga2V5ID0gIiV7JXtjb250cm9sOlN0YXRlfTot > > > JXsle3JlcGx5OlN0YXRlfTotJXtTdGF0ZX19fSINCiAgICAgICAgdHRsID0gMTUNCiAgICAgICAg > > > bWF4X2VudHJpZXMgPSAxNjM4NA0KICAgICAgICBlcG9jaCA9IDANCiAgICAgICAgYWRkX3N0YXRz > > > ID0gbm8NCiAgfQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX2NoYXANCiAgIyBJbnN0YW50aWF0aW5n > > > IG1vZHVsZSAiY2hhcCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2NoYXANCiAg > > > IyBMb2FkZWQgbW9kdWxlIHJsbV9kZXRhaWwNCiAgIyBJbnN0YW50aWF0aW5nIG1vZHVsZSAiZGV0 > > > YWlsIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZGV0YWlsDQogIGRldGFpbCB7 > > > DQogICAgICAgIGZpbGVuYW1lID0gIi92YXIvbG9nL3JhZGl1cy9yYWRhY2N0LyV7JXtQYWNrZXQt > > > U3JjLUlQLUFkZHJlc3N9Oi0le1BhY2tldC1TcmMtSVB2Ni1BZGRyZXNzfX0vZGV0YWlsLSVZJW0l > > > ZCINCiAgICAgICAgaGVhZGVyID0gIiV0Ig0KICAgICAgICBwZXJtaXNzaW9ucyA9IDM4NA0KICAg > > > ICAgICBsb2NraW5nID0gbm8NCiAgICAgICAgbG9nX3BhY2tldF9oZWFkZXIgPSBubw0KICB9DQog > > > ICMgSW5zdGFudGlhdGluZyBtb2R1bGUgImF1dGhfbG9nIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9t > > > b2RzLWVuYWJsZWQvZGV0YWlsLmxvZw0KICBkZXRhaWwgYXV0aF9sb2cgew0KICAgICAgICBmaWxl > > > bmFtZSA9ICIvdmFyL2xvZy9yYWRpdXMvcmFkYWNjdC8leyV7UGFja2V0LVNyYy1JUC1BZGRyZXNz > > > fTotJXtQYWNrZXQtU3JjLUlQdjYtQWRkcmVzc319L2F1dGgtZGV0YWlsLSVZJW0lZCINCiAgICAg > > > ICAgaGVhZGVyID0gIiV0Ig0KICAgICAgICBwZXJtaXNzaW9ucyA9IDM4NA0KICAgICAgICBsb2Nr > > > aW5nID0gbm8NCiAgICAgICAgbG9nX3BhY2tldF9oZWFkZXIgPSBubw0KICB9DQpybG1fZGV0YWls > > > IChhdXRoX2xvZyk6ICdVc2VyLVBhc3N3b3JkJyBzdXBwcmVzc2VkLCB3aWxsIG5vdCBhcHBlYXIg > > > aW4gZGV0YWlsIG91dHB1dA0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJyZXBseV9sb2ciIGZy > > > b20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9kZXRhaWwubG9nDQogIGRldGFpbCByZXBs > > > eV9sb2cgew0KICAgICAgICBmaWxlbmFtZSA9ICIvdmFyL2xvZy9yYWRpdXMvcmFkYWNjdC8leyV7 > > > UGFja2V0LVNyYy1JUC1BZGRyZXNzfTotJXtQYWNrZXQtU3JjLUlQdjYtQWRkcmVzc319L3JlcGx5 > > > LWRldGFpbC0lWSVtJWQiDQogICAgICAgIGhlYWRlciA9ICIldCINCiAgICAgICAgcGVybWlzc2lv > > > bnMgPSAzODQNCiAgICAgICAgbG9ja2luZyA9IG5vDQogICAgICAgIGxvZ19wYWNrZXRfaGVhZGVy > > > ID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJwcmVfcHJveHlfbG9nIiBmcm9t > > > IGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZGV0YWlsLmxvZw0KICBkZXRhaWwgcHJlX3By > > > b3h5X2xvZyB7DQogICAgICAgIGZpbGVuYW1lID0gIi92YXIvbG9nL3JhZGl1cy9yYWRhY2N0LyV7 > > > JXtQYWNrZXQtU3JjLUlQLUFkZHJlc3N9Oi0le1BhY2tldC1TcmMtSVB2Ni1BZGRyZXNzfX0vcHJl > > > LXByb3h5LWRldGFpbC0lWSVtJWQiDQogICAgICAgIGhlYWRlciA9ICIldCINCiAgICAgICAgcGVy > > > bWlzc2lvbnMgPSAzODQNCiAgICAgICAgbG9ja2luZyA9IG5vDQogICAgICAgIGxvZ19wYWNrZXRf > > > aGVhZGVyID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJwb3N0X3Byb3h5X2xv > > > ZyIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2RldGFpbC5sb2cNCiAgZGV0YWls > > > IHBvc3RfcHJveHlfbG9nIHsNCiAgICAgICAgZmlsZW5hbWUgPSAiL3Zhci9sb2cvcmFkaXVzL3Jh > > > ZGFjY3QvJXsle1BhY2tldC1TcmMtSVAtQWRkcmVzc306LSV7UGFja2V0LVNyYy1JUHY2LUFkZHJl > > > c3N9fS9wb3N0LXByb3h5LWRldGFpbC0lWSVtJWQiDQogICAgICAgIGhlYWRlciA9ICIldCINCiAg > > > ICAgICAgcGVybWlzc2lvbnMgPSAzODQNCiAgICAgICAgbG9ja2luZyA9IG5vDQogICAgICAgIGxv > > > Z19wYWNrZXRfaGVhZGVyID0gbm8NCiAgfQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX2RoY3ANCiAg > > > IyBJbnN0YW50aWF0aW5nIG1vZHVsZSAiZGhjcCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1l > > > bmFibGVkL2RoY3ANCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV9kaWdlc3QNCiAgIyBJbnN0YW50aWF0 > > > aW5nIG1vZHVsZSAiZGlnZXN0IiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZGln > > > ZXN0DQogICMgTG9hZGVkIG1vZHVsZSBybG1fZHluYW1pY19jbGllbnRzDQogICMgSW5zdGFudGlh > > > dGluZyBtb2R1bGUgImR5bmFtaWNfY2xpZW50cyIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1l > > > bmFibGVkL2R5bmFtaWNfY2xpZW50cw0KICAjIExvYWRlZCBtb2R1bGUgcmxtX2VhcA0KICAjIElu > > > c3RhbnRpYXRpbmcgbW9kdWxlICJlYXAiIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxl > > > ZC9lYXANCiAgZWFwIHsNCiAgICAgICAgZGVmYXVsdF9lYXBfdHlwZSA9ICJwZWFwIg0KICAgICAg > > > ICB0aW1lcl9leHBpcmUgPSA2MA0KICAgICAgICBpZ25vcmVfdW5rbm93bl9lYXBfdHlwZXMgPSBu > > > bw0KICAgICAgICBtb2RfYWNjb3VudGluZ191c2VybmFtZV9idWcgPSBubw0KICAgICAgICBtYXhf > > > c2Vzc2lvbnMgPSAxMDI0DQogIH0NCiAgICMgTGlua2VkIHRvIHN1Yi1tb2R1bGUgcmxtX2VhcF9t > > > ZDUNCiAgICMgTGlua2VkIHRvIHN1Yi1tb2R1bGUgcmxtX2VhcF9sZWFwDQogICAjIExpbmtlZCB0 > > > byBzdWItbW9kdWxlIHJsbV9lYXBfZ3RjDQogICBndGMgew0KICAgICAgICBjaGFsbGVuZ2UgPSAi > > > UGFzc3dvcmQ6ICINCiAgICAgICAgYXV0aF90eXBlID0gIlBBUCINCiAgIH0NCiAgICMgTGlua2Vk > > > IHRvIHN1Yi1tb2R1bGUgcmxtX2VhcF90bHMNCiAgIHRscyB7DQogICAgICAgIHRscyA9ICJ0bHMt > > > Y29tbW9uIg0KICAgfQ0KICAgdGxzLWNvbmZpZyB0bHMtY29tbW9uIHsNCiAgICAgICAgcnNhX2tl > > > eV9leGNoYW5nZSA9IG5vDQogICAgICAgIGRoX2tleV9leGNoYW5nZSA9IHllcw0KICAgICAgICBy > > > c2Ffa2V5X2xlbmd0aCA9IDUxMg0KICAgICAgICBkaF9rZXlfbGVuZ3RoID0gNTEyDQogICAgICAg > > > IHZlcmlmeV9kZXB0aCA9IDANCiAgICAgICAgY2FfcGF0aCA9ICIvZXRjL3JhZGRiL2NlcnRzIg0K > > > ICAgICAgICBwZW1fZmlsZV90eXBlID0geWVzDQogICAgICAgIHByaXZhdGVfa2V5X2ZpbGUgPSAi > > > L2V0Yy9yYWRkYi9jZXJ0cy9zZXJ2ZXIucGVtIg0KICAgICAgICBjZXJ0aWZpY2F0ZV9maWxlID0g > > > Ii9ldGMvcmFkZGIvY2VydHMvc2VydmVyLnBlbSINCiAgICAgICAgY2FfZmlsZSA9ICIvZXRjL3Jh > > > ZGRiL2NlcnRzL2NhLnBlbSINCiAgICAgICAgcHJpdmF0ZV9rZXlfcGFzc3dvcmQgPSA8PDwgc2Vj > > > cmV0ID4+Pg0KICAgICAgICBkaF9maWxlID0gIi9ldGMvcmFkZGIvY2VydHMvZGgiDQogICAgICAg > > > IGZyYWdtZW50X3NpemUgPSAxMDI0DQogICAgICAgIGluY2x1ZGVfbGVuZ3RoID0geWVzDQogICAg > > > ICAgIGNoZWNrX2NybCA9IG5vDQogICAgICAgIGNpcGhlcl9saXN0ID0gIkRFRkFVTFQiDQogICAg > > > ICAgIGVjZGhfY3VydmUgPSAicHJpbWUyNTZ2MSINCiAgICBjYWNoZSB7DQogICAgICAgIGVuYWJs > > > ZSA9IHllcw0KICAgICAgICBsaWZldGltZSA9IDI0DQogICAgICAgIG1heF9lbnRyaWVzID0gMjU1 > > > DQogICAgfQ0KICAgIHZlcmlmeSB7DQogICAgfQ0KICAgIG9jc3Agew0KICAgICAgICBlbmFibGUg > > > PSBubw0KICAgICAgICBvdmVycmlkZV9jZXJ0X3VybCA9IHllcw0KICAgICAgICB1cmwgPSAiaHR0 > > > cDovLzEyNy4wLjAuMS9vY3NwLyINCiAgICAgICAgdXNlX25vbmNlID0geWVzDQogICAgICAgIHRp > > > bWVvdXQgPSAwDQogICAgICAgIHNvZnRmYWlsID0geWVzDQogICAgfQ0KICAgfQ0KICAgIyBMaW5r > > > ZWQgdG8gc3ViLW1vZHVsZSBybG1fZWFwX3R0bHMNCiAgIHR0bHMgew0KICAgICAgICB0bHMgPSAi > > > dGxzLWNvbW1vbiINCiAgICAgICAgZGVmYXVsdF9lYXBfdHlwZSA9ICJtZDUiDQogICAgICAgIGNv > > > cHlfcmVxdWVzdF90b190dW5uZWwgPSBubw0KICAgICAgICB1c2VfdHVubmVsZWRfcmVwbHkgPSBu > > > bw0KICAgICAgICB2aXJ0dWFsX3NlcnZlciA9ICJpbm5lci10dW5uZWwiDQogICAgICAgIGluY2x1 > > > ZGVfbGVuZ3RoID0geWVzDQogICAgICAgIHJlcXVpcmVfY2xpZW50X2NlcnQgPSBubw0KICAgfQ0K > > > VXNpbmcgY2FjaGVkIFRMUyBjb25maWd1cmF0aW9uIGZyb20gcHJldmlvdXMgaW52b2NhdGlvbg0K > > > ICAgIyBMaW5rZWQgdG8gc3ViLW1vZHVsZSBybG1fZWFwX3BlYXANCiAgIHBlYXAgew0KICAgICAg > > > ICB0bHMgPSAidGxzLWNvbW1vbiINCiAgICAgICAgZGVmYXVsdF9tZXRob2QgPSAibXNjaGFwdjIi > > > DQogICAgICAgIGNvcHlfcmVxdWVzdF90b190dW5uZWwgPSBubw0KICAgICAgICB1c2VfdHVubmVs > > > ZWRfcmVwbHkgPSBubw0KICAgICAgICBwcm94eV90dW5uZWxlZF9yZXF1ZXN0X2FzX2VhcCA9IHll > > > cw0KICAgICAgICB2aXJ0dWFsX3NlcnZlciA9ICJpbm5lci10dW5uZWwiDQogICAgICAgIHNvaCA9 > > > IG5vDQogICAgICAgIHJlcXVpcmVfY2xpZW50X2NlcnQgPSBubw0KICAgfQ0KVXNpbmcgY2FjaGVk > > > IFRMUyBjb25maWd1cmF0aW9uIGZyb20gcHJldmlvdXMgaW52b2NhdGlvbg0KICAgIyBMaW5rZWQg > > > dG8gc3ViLW1vZHVsZSBybG1fZWFwX21zY2hhcHYyDQogICBtc2NoYXB2MiB7DQogICAgICAgIHdp > > > dGhfbnRkb21haW5faGFjayA9IG5vDQogICAgICAgIHNlbmRfZXJyb3IgPSBubw0KICAgfQ0KICAj > > > IExvYWRlZCBtb2R1bGUgcmxtX2V4ZWMNCiAgIyBJbnN0YW50aWF0aW5nIG1vZHVsZSAiZWNobyIg > > > ZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2VjaG8NCiAgZXhlYyBlY2hvIHsNCiAg > > > ICAgICAgd2FpdCA9IHllcw0KICAgICAgICBwcm9ncmFtID0gIi9iaW4vZWNobyAle1VzZXItTmFt > > > ZX0iDQogICAgICAgIGlucHV0X3BhaXJzID0gInJlcXVlc3QiDQogICAgICAgIG91dHB1dF9wYWly > > > cyA9ICJyZXBseSINCiAgICAgICAgc2hlbGxfZXNjYXBlID0geWVzDQogIH0NCiAgIyBJbnN0YW50 > > > aWF0aW5nIG1vZHVsZSAiZXhlYyIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2V4 > > > ZWMNCiAgZXhlYyB7DQogICAgICAgIHdhaXQgPSBubw0KICAgICAgICBpbnB1dF9wYWlycyA9ICJy > > > ZXF1ZXN0Ig0KICAgICAgICBzaGVsbF9lc2NhcGUgPSB5ZXMNCiAgICAgICAgdGltZW91dCA9IDEw > > > DQogIH0NCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV9leHBpcmF0aW9uDQogICMgSW5zdGFudGlhdGlu > > > ZyBtb2R1bGUgImV4cGlyYXRpb24iIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9l > > > eHBpcmF0aW9uDQogICMgTG9hZGVkIG1vZHVsZSBybG1fZXhwcg0KICAjIEluc3RhbnRpYXRpbmcg > > > bW9kdWxlICJleHByIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZXhwcg0KICBl > > > eHByIHsNCiAgICAgICAgc2FmZV9jaGFyYWN0ZXJzID0gIkBhYmNkZWZnaGlqa2xtbm9wcXJzdHV2 > > > d3h5ekFCQ0RFRkdISUpLTE1OT1BRUlNUVVZXWFlaMDEyMzQ1Njc4OS4tXzogLyINCiAgfQ0KICAj > > > IExvYWRlZCBtb2R1bGUgcmxtX2ZpbGVzDQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgImZpbGVz > > > IiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvZmlsZXMNCiAgZmlsZXMgew0KICAg > > > ICAgICBmaWxlbmFtZSA9ICIvZXRjL3JhZGRiL21vZHMtY29uZmlnL2ZpbGVzL2F1dGhvcml6ZSIN > > > CiAgICAgICAgdXNlcnNmaWxlID0gIi9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmlsZXMvYXV0aG9y > > > aXplIg0KICAgICAgICBhY2N0dXNlcnNmaWxlID0gIi9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmls > > > ZXMvYWNjb3VudGluZyINCiAgICAgICAgcHJlcHJveHlfdXNlcnNmaWxlID0gIi9ldGMvcmFkZGIv > > > bW9kcy1jb25maWcvZmlsZXMvcHJlLXByb3h5Ig0KICAgICAgICBjb21wYXQgPSAiY2lzdHJvbiIN > > > CiAgfQ0KcmVhZGluZyBwYWlybGlzdCBmaWxlIC9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmlsZXMv > > > YXV0aG9yaXplDQpbL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9maWxlcy9hdXRob3JpemVdOjE4MiBD > > > aXN0cm9uIGNvbXBhdGliaWxpdHkgY2hlY2tzIGZvciBlbnRyeSBERUZBVUxUIC4uLg0KWy9ldGMv > > > cmFkZGIvbW9kcy1jb25maWcvZmlsZXMvYXV0aG9yaXplXToxODQgQ2lzdHJvbiBjb21wYXRpYmls > > > aXR5IGNoZWNrcyBmb3IgZW50cnkgREVGQVVMVCAuLi4NClsvZXRjL3JhZGRiL21vZHMtY29uZmln > > > L2ZpbGVzL2F1dGhvcml6ZV06MTkxIENpc3Ryb24gY29tcGF0aWJpbGl0eSBjaGVja3MgZm9yIGVu > > > dHJ5IERFRkFVTFQgLi4uDQpbL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9maWxlcy9hdXRob3JpemVd > > > OjE5OCBDaXN0cm9uIGNvbXBhdGliaWxpdHkgY2hlY2tzIGZvciBlbnRyeSBERUZBVUxUIC4uLg0K > > > cmVhZGluZyBwYWlybGlzdCBmaWxlIC9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmlsZXMvYXV0aG9y > > > aXplDQpbL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9maWxlcy9hdXRob3JpemVdOjE4MiBDaXN0cm9u > > > IGNvbXBhdGliaWxpdHkgY2hlY2tzIGZvciBlbnRyeSBERUZBVUxUIC4uLg0KWy9ldGMvcmFkZGIv > > > bW9kcy1jb25maWcvZmlsZXMvYXV0aG9yaXplXToxODQgQ2lzdHJvbiBjb21wYXRpYmlsaXR5IGNo > > > ZWNrcyBmb3IgZW50cnkgREVGQVVMVCAuLi4NClsvZXRjL3JhZGRiL21vZHMtY29uZmlnL2ZpbGVz > > > L2F1dGhvcml6ZV06MTkxIENpc3Ryb24gY29tcGF0aWJpbGl0eSBjaGVja3MgZm9yIGVudHJ5IERF > > > RkFVTFQgLi4uDQpbL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9maWxlcy9hdXRob3JpemVdOjE5OCBD > > > aXN0cm9uIGNvbXBhdGliaWxpdHkgY2hlY2tzIGZvciBlbnRyeSBERUZBVUxUIC4uLg0KcmVhZGlu > > > ZyBwYWlybGlzdCBmaWxlIC9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmlsZXMvYWNjb3VudGluZw0K > > > cmVhZGluZyBwYWlybGlzdCBmaWxlIC9ldGMvcmFkZGIvbW9kcy1jb25maWcvZmlsZXMvcHJlLXBy > > > b3h5DQogICMgTG9hZGVkIG1vZHVsZSBybG1fbGluZWxvZw0KICAjIEluc3RhbnRpYXRpbmcgbW9k > > > dWxlICJsaW5lbG9nIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvbGluZWxvZw0K > > > ICBsaW5lbG9nIHsNCiAgICAgICAgZmlsZW5hbWUgPSAiL3Zhci9sb2cvcmFkaXVzL2xpbmVsb2ci > > > DQogICAgICAgIHBlcm1pc3Npb25zID0gMzg0DQogICAgICAgIGZvcm1hdCA9ICJUaGlzIGlzIGEg > > > bG9nIG1lc3NhZ2UgZm9yICV7VXNlci1OYW1lfSINCiAgICAgICAgcmVmZXJlbmNlID0gIm1lc3Nh > > > Z2VzLiV7JXtQYWNrZXQtVHlwZX06LWRlZmF1bHR9Ig0KICB9DQogICMgSW5zdGFudGlhdGluZyBt > > > b2R1bGUgImxvZ19hY2NvdW50aW5nIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQv > > > bGluZWxvZw0KICBsaW5lbG9nIGxvZ19hY2NvdW50aW5nIHsNCiAgICAgICAgZmlsZW5hbWUgPSAi > > > L3Zhci9sb2cvcmFkaXVzL2xpbmVsb2ctYWNjb3VudGluZyINCiAgICAgICAgcGVybWlzc2lvbnMg > > > PSAzODQNCiAgICAgICAgZm9ybWF0ID0gIiINCiAgICAgICAgcmVmZXJlbmNlID0gIkFjY291bnRp > > > bmctUmVxdWVzdC4leyV7QWNjdC1TdGF0dXMtVHlwZX06LXVua25vd259Ig0KICB9DQogICMgTG9h > > > ZGVkIG1vZHVsZSBybG1fbG9naW50aW1lDQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgImxvZ2lu > > > dGltZSIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL2xvZ2ludGltZQ0KICBsb2dp > > > bnRpbWUgew0KICAgICAgICBtaW5pbXVtX3RpbWVvdXQgPSA2MA0KICB9DQogICMgTG9hZGVkIG1v > > > ZHVsZSBybG1fbXNjaGFwDQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgIm1zY2hhcCIgZnJvbSBm > > > aWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL21zY2hhcA0KICBtc2NoYXAgew0KICAgICAgICB1 > > > c2VfbXBwZSA9IHllcw0KICAgICAgICByZXF1aXJlX2VuY3J5cHRpb24gPSB5ZXMNCiAgICAgICAg > > > cmVxdWlyZV9zdHJvbmcgPSB5ZXMNCiAgICAgICAgd2l0aF9udGRvbWFpbl9oYWNrID0geWVzDQog > > > ICAgICAgIG50bG1fYXV0aCA9ICIvdXNyL2Jpbi9udGxtX2F1dGggLS1yZXF1ZXN0LW50LWtleSAt > > > LXVzZXJuYW1lPSV7JXtTdHJpcHBlZC1Vc2VyLU5hbWV9Oi0leyV7VXNlci1OYW1lfTotTm9uZX19 > > > IC0tY2hhbGxlbmdlPSV7JXttc2NoYXA6Q2hhbGxlbmdlfTotMDB9IC0tbnQtcmVzcG9uc2U9JXsl > > > e21zY2hhcDpOVC1SZXNwb25zZX06LTAwfSAtLWRvbWFpbj0le21zY2hhcDpOVC1Eb21haW59ICIN > > > CiAgIHBhc3NjaGFuZ2Ugew0KICAgfQ0KICAgICAgICBhbGxvd19yZXRyeSA9IHllcw0KICB9DQog > > > ICMgSW5zdGFudGlhdGluZyBtb2R1bGUgIm50bG1fYXV0aCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIv > > > bW9kcy1lbmFibGVkL250bG1fYXV0aA0KICBleGVjIG50bG1fYXV0aCB7DQogICAgICAgIHdhaXQg > > > PSB5ZXMNCiAgICAgICAgcHJvZ3JhbSA9ICIvcGF0aC90by9udGxtX2F1dGggLS1yZXF1ZXN0LW50 > > > LWtleSAtLWRvbWFpbj1NWURPTUFJTiAtLXVzZXJuYW1lPSV7bXNjaGFwOlVzZXItTmFtZX0gLS1w > > > YXNzd29yZD0le1VzZXItUGFzc3dvcmR9Ig0KICAgICAgICBzaGVsbF9lc2NhcGUgPSB5ZXMNCiAg > > > fQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX3BhcA0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJw > > > YXAiIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9wYXANCiAgcGFwIHsNCiAgICAg > > > ICAgbm9ybWFsaXNlID0geWVzDQogIH0NCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV9wYXNzd2QNCiAg > > > IyBJbnN0YW50aWF0aW5nIG1vZHVsZSAiZXRjX3Bhc3N3ZCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIv > > > bW9kcy1lbmFibGVkL3Bhc3N3ZA0KICBwYXNzd2QgZXRjX3Bhc3N3ZCB7DQogICAgICAgIGZpbGVu > > > YW1lID0gIi9ldGMvcGFzc3dkIg0KICAgICAgICBmb3JtYXQgPSAiKlVzZXItTmFtZTpDcnlwdC1Q > > > YXNzd29yZDoiDQogICAgICAgIGRlbGltaXRlciA9ICI6Ig0KICAgICAgICBpZ25vcmVfbmlzbGlr > > > ZSA9IG5vDQogICAgICAgIGlnbm9yZV9lbXB0eSA9IHllcw0KICAgICAgICBhbGxvd19tdWx0aXBs > > > ZV9rZXlzID0gbm8NCiAgICAgICAgaGFzaF9zaXplID0gMTAwDQogIH0NCnJsbV9wYXNzd2Q6IG5m > > > aWVsZHM6IDMga2V5ZmllbGQgMChVc2VyLU5hbWUpIGxpc3RhYmxlOiBubw0KICAjIExvYWRlZCBt > > > b2R1bGUgcmxtX3ByZXByb2Nlc3MNCiAgIyBJbnN0YW50aWF0aW5nIG1vZHVsZSAicHJlcHJvY2Vz > > > cyIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL3ByZXByb2Nlc3MNCiAgcHJlcHJv > > > Y2VzcyB7DQogICAgICAgIGh1bnRncm91cHMgPSAiL2V0Yy9yYWRkYi9tb2RzLWNvbmZpZy9wcmVw > > > cm9jZXNzL2h1bnRncm91cHMiDQogICAgICAgIGhpbnRzID0gIi9ldGMvcmFkZGIvbW9kcy1jb25m > > > aWcvcHJlcHJvY2Vzcy9oaW50cyINCiAgICAgICAgd2l0aF9hc2NlbmRfaGFjayA9IG5vDQogICAg > > > ICAgIGFzY2VuZF9jaGFubmVsc19wZXJfbGluZSA9IDIzDQogICAgICAgIHdpdGhfbnRkb21haW5f > > > aGFjayA9IG5vDQogICAgICAgIHdpdGhfc3BlY2lhbGl4X2pldHN0cmVhbV9oYWNrID0gbm8NCiAg > > > ICAgICAgd2l0aF9jaXNjb192c2FfaGFjayA9IG5vDQogICAgICAgIHdpdGhfYWx2YXJpb25fdnNh > > > X2hhY2sgPSBubw0KICB9DQpyZWFkaW5nIHBhaXJsaXN0IGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWNv > > > bmZpZy9wcmVwcm9jZXNzL2h1bnRncm91cHMNCnJlYWRpbmcgcGFpcmxpc3QgZmlsZSAvZXRjL3Jh > > > ZGRiL21vZHMtY29uZmlnL3ByZXByb2Nlc3MvaGludHMNCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV9y > > > YWR1dG1wDQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgInJhZHV0bXAiIGZyb20gZmlsZSAvZXRj > > > L3JhZGRiL21vZHMtZW5hYmxlZC9yYWR1dG1wDQogIHJhZHV0bXAgew0KICAgICAgICBmaWxlbmFt > > > ZSA9ICIvdmFyL2xvZy9yYWRpdXMvcmFkdXRtcCINCiAgICAgICAgdXNlcm5hbWUgPSAiJXtVc2Vy > > > LU5hbWV9Ig0KICAgICAgICBjYXNlX3NlbnNpdGl2ZSA9IHllcw0KICAgICAgICBjaGVja193aXRo > > > X25hcyA9IHllcw0KICAgICAgICBwZXJtaXNzaW9ucyA9IDM4NA0KICAgICAgICBjYWxsZXJfaWQg > > > PSB5ZXMNCiAgfQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX3JlYWxtDQogICMgSW5zdGFudGlhdGlu > > > ZyBtb2R1bGUgIklQQVNTIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvcmVhbG0N > > > CiAgcmVhbG0gSVBBU1Mgew0KICAgICAgICBmb3JtYXQgPSAicHJlZml4Ig0KICAgICAgICBkZWxp > > > bWl0ZXIgPSAiLyINCiAgICAgICAgaWdub3JlX2RlZmF1bHQgPSBubw0KICAgICAgICBpZ25vcmVf > > > bnVsbCA9IG5vDQogIH0NCiAgIyBJbnN0YW50aWF0aW5nIG1vZHVsZSAic3VmZml4IiBmcm9tIGZp > > > bGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvcmVhbG0NCiAgcmVhbG0gc3VmZml4IHsNCiAgICAg > > > ICAgZm9ybWF0ID0gInN1ZmZpeCINCiAgICAgICAgZGVsaW1pdGVyID0gIkAiDQogICAgICAgIGln > > > bm9yZV9kZWZhdWx0ID0gbm8NCiAgICAgICAgaWdub3JlX251bGwgPSBubw0KICB9DQogICMgSW5z > > > dGFudGlhdGluZyBtb2R1bGUgInJlYWxtcGVyY2VudCIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9k > > > cy1lbmFibGVkL3JlYWxtDQogIHJlYWxtIHJlYWxtcGVyY2VudCB7DQogICAgICAgIGZvcm1hdCA9 > > > ICJzdWZmaXgiDQogICAgICAgIGRlbGltaXRlciA9ICIlIg0KICAgICAgICBpZ25vcmVfZGVmYXVs > > > dCA9IG5vDQogICAgICAgIGlnbm9yZV9udWxsID0gbm8NCiAgfQ0KICAjIEluc3RhbnRpYXRpbmcg > > > bW9kdWxlICJudGRvbWFpbiIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL3JlYWxt > > > DQogIHJlYWxtIG50ZG9tYWluIHsNCiAgICAgICAgZm9ybWF0ID0gInByZWZpeCINCiAgICAgICAg > > > ZGVsaW1pdGVyID0gIlwiDQogICAgICAgIGlnbm9yZV9kZWZhdWx0ID0gbm8NCiAgICAgICAgaWdu > > > b3JlX251bGwgPSBubw0KICB9DQogICMgTG9hZGVkIG1vZHVsZSBybG1fcmVwbGljYXRlDQogICMg > > > SW5zdGFudGlhdGluZyBtb2R1bGUgInJlcGxpY2F0ZSIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9k > > > cy1lbmFibGVkL3JlcGxpY2F0ZQ0KICAjIExvYWRlZCBtb2R1bGUgcmxtX3NvaA0KICAjIEluc3Rh > > > bnRpYXRpbmcgbW9kdWxlICJzb2giIGZyb20gZmlsZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC9z > > > b2gNCiAgc29oIHsNCiAgICAgICAgZGhjcCA9IHllcw0KICB9DQogICMgSW5zdGFudGlhdGluZyBt > > > b2R1bGUgInNyYWR1dG1wIiBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvc3JhZHV0 > > > bXANCiAgcmFkdXRtcCBzcmFkdXRtcCB7DQogICAgICAgIGZpbGVuYW1lID0gIi92YXIvbG9nL3Jh > > > ZGl1cy9zcmFkdXRtcCINCiAgICAgICAgdXNlcm5hbWUgPSAiJXtVc2VyLU5hbWV9Ig0KICAgICAg > > > ICBjYXNlX3NlbnNpdGl2ZSA9IHllcw0KICAgICAgICBjaGVja193aXRoX25hcyA9IHllcw0KICAg > > > ICAgICBwZXJtaXNzaW9ucyA9IDQyMA0KICAgICAgICBjYWxsZXJfaWQgPSBubw0KICB9DQogICMg > > > TG9hZGVkIG1vZHVsZSBybG1fdW5peA0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJ1bml4IiBm > > > cm9tIGZpbGUgL2V0Yy9yYWRkYi9tb2RzLWVuYWJsZWQvdW5peA0KICB1bml4IHsNCiAgICAgICAg > > > cmFkd3RtcCA9ICIvdmFyL2xvZy9yYWRpdXMvcmFkd3RtcCINCiAgfQ0KICAjIExvYWRlZCBtb2R1 > > > bGUgcmxtX3VucGFjaw0KICAjIEluc3RhbnRpYXRpbmcgbW9kdWxlICJ1bnBhY2siIGZyb20gZmls > > > ZSAvZXRjL3JhZGRiL21vZHMtZW5hYmxlZC91bnBhY2sNCiAgIyBMb2FkZWQgbW9kdWxlIHJsbV91 > > > dGY4DQogICMgSW5zdGFudGlhdGluZyBtb2R1bGUgInV0ZjgiIGZyb20gZmlsZSAvZXRjL3JhZGRi > > > L21vZHMtZW5hYmxlZC91dGY4DQogICMgTG9hZGVkIG1vZHVsZSBybG1fcGFtDQogICMgSW5zdGFu > > > dGlhdGluZyBtb2R1bGUgInBhbSIgZnJvbSBmaWxlIC9ldGMvcmFkZGIvbW9kcy1lbmFibGVkL3Bh > > > bQ0KICBwYW0gew0KICAgICAgICBwYW1fYXV0aCA9ICJyYWRpdXNkIg0KICB9DQogfSAjIG1vZHVs > > > ZXMNCnJhZGl1c2Q6ICMjIyMgTG9hZGluZyBWaXJ0dWFsIFNlcnZlcnMgIyMjIw0Kc2VydmVyIHsg > > > IyBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9yYWRpdXNkLmNvbmYNCn0gIyBzZXJ2ZXINCnNlcnZlciBk > > > ZWZhdWx0IHsgIyBmcm9tIGZpbGUgL2V0Yy9yYWRkYi9zaXRlcy1lbmFibGVkL2RlZmF1bHQNCiAj > > > IExvYWRpbmcgYXV0aGVudGljYXRlIHsuLi59DQogIyBMb2FkaW5nIGF1dGhvcml6ZSB7Li4ufQ0K > > > SWdub3JpbmcgInNxbCIgKHNlZSByYWRkYi9tb2RzLWF2YWlsYWJsZS9SRUFETUUucnN0KQ0KSWdu > > > b3JpbmcgImxkYXAiIChzZWUgcmFkZGIvbW9kcy1hdmFpbGFibGUvUkVBRE1FLnJzdCkNCiAjIExv > > > YWRpbmcgcHJlYWNjdCB7Li4ufQ0KICMgTG9hZGluZyBhY2NvdW50aW5nIHsuLi59DQogIyBMb2Fk > > > aW5nIHBvc3QtcHJveHkgey4uLn0NCiAjIExvYWRpbmcgcG9zdC1hdXRoIHsuLi59DQp9ICMgc2Vy > > > dmVyIGRlZmF1bHQNCnNlcnZlciBpbm5lci10dW5uZWwgeyAjIGZyb20gZmlsZSAvZXRjL3JhZGRi > > > L3NpdGVzLWVuYWJsZWQvaW5uZXItdHVubmVsDQogIyBMb2FkaW5nIGF1dGhlbnRpY2F0ZSB7Li4u > > > fQ0KICMgTG9hZGluZyBhdXRob3JpemUgey4uLn0NCiAjIExvYWRpbmcgc2Vzc2lvbiB7Li4ufQ0K > > > ICMgTG9hZGluZyBwb3N0LXByb3h5IHsuLi59DQogIyBMb2FkaW5nIHBvc3QtYXV0aCB7Li4ufQ0K > > > fSAjIHNlcnZlciBpbm5lci10dW5uZWwNCnJhZGl1c2Q6ICMjIyMgT3BlbmluZyBJUCBhZGRyZXNz > > > ZXMgYW5kIFBvcnRzICMjIyMNCmxpc3RlbiB7DQogICAgICAgIHR5cGUgPSAiYXV0aCINCiAgICAg > > > ICAgaXBhZGRyID0gKg0KICAgICAgICBwb3J0ID0gMA0KICAgbGltaXQgew0KICAgICAgICBtYXhf > > > Y29ubmVjdGlvbnMgPSAxNg0KICAgICAgICBsaWZldGltZSA9IDANCiAgICAgICAgaWRsZV90aW1l > > > b3V0ID0gMzANCiAgIH0NCn0NCmxpc3RlbiB7DQogICAgICAgIHR5cGUgPSAiYWNjdCINCiAgICAg > > > ICAgaXBhZGRyID0gKg0KICAgICAgICBwb3J0ID0gMA0KICAgbGltaXQgew0KICAgICAgICBtYXhf > > > Y29ubmVjdGlvbnMgPSAxNg0KICAgICAgICBsaWZldGltZSA9IDANCiAgICAgICAgaWRsZV90aW1l > > > b3V0ID0gMzANCiAgIH0NCn0NCmxpc3RlbiB7DQogICAgICAgIHR5cGUgPSAiYXV0aCINCiAgICAg > > > ICAgaXB2NmFkZHIgPSA6Og0KICAgICAgICBwb3J0ID0gMA0KICAgbGltaXQgew0KICAgICAgICBt > > > YXhfY29ubmVjdGlvbnMgPSAxNg0KICAgICAgICBsaWZldGltZSA9IDANCiAgICAgICAgaWRsZV90 > > > aW1lb3V0ID0gMzANCiAgIH0NCn0NCmxpc3RlbiB7DQogICAgICAgIHR5cGUgPSAiYWNjdCINCiAg > > > ICAgICAgaXB2NmFkZHIgPSA6Og0KICAgICAgICBwb3J0ID0gMA0KICAgbGltaXQgew0KICAgICAg > > > ICBtYXhfY29ubmVjdGlvbnMgPSAxNg0KICAgICAgICBsaWZldGltZSA9IDANCiAgICAgICAgaWRs > > > ZV90aW1lb3V0ID0gMzANCiAgIH0NCn0NCmxpc3RlbiB7DQogICAgICAgIHR5cGUgPSAiYXV0aCIN > > CiAgICAgICAgaXBhZGRyID0gMTI3LjAuMC4xDQogICAgICAgIHBvcnQgPSAxODEyMA0KfQ0K > > --047d7bb03dce1c3453051bb8b92a-- > > > >

2 2

Rewriting realms
by Jamie Orzechowski 25 Jul '15

25 Jul '15

I am a fresh convert from Radiator to FreeRadius. How do I strip off everything after the @ in the received username and append @newrealm.com?

3 5

Re: AD Authentication using PAM_winbind.so succeeds, but FreeRadius 3.0.4 rejects with "Failed to Authenticate User"
by Josh Miller 25 Jul '15

25 Jul '15

Hello, I am attempting to configure 2 factor authentication using Google Authenticator + AD (Winbind), ultimately for use in my Cisco and Windows VPN environment. The environment is as follows: -Fedora 22 -Freeradius 3.0.4 -Samba 4.2.2 Authentication using Winbind is successful and the journalCTL log files verifies this as you will see below. For testing purposes, I've disabled Google Authenticator line in the /etc/pam.d/radiusd config file so I can focus on PAM_Winbind functionality. This is the only line that I'm using. ---------------------- #/etc/pam.d/radius auth required /usr/lib64/security/pam_winbind.so debug ---------------------- When I authenticate via radtest I get rejected: ------------ [root@hlsfreeradius01 ~]# radtest -x -t pap test-user-123 test-password localhost 1812 testing123 Sending Access-Request Id 172 from 0.0.0.0:55300 to 127.0.0.1:1812 User-Name = 'test-user-123' User-Password = 'test-password' NAS-IP-Address = 10.101.1.8 NAS-Port = 1812 Message-Authenticator = 0x00 Received Access-Reject Id 172 from 127.0.0.1:1812 to 127.0.0.1:55300 length 20 (0) -: Expected Access-Accept got Access-Reject -------------- Here is the JournalCTL output from Fedora that proves the winbind was successful: ---------------------- Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): [pamh: 0x7f0bff4029c0] ENTER: pam_sm_authenticate (flags: 0x0000) J ul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): getting password (0x00000001) Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): Verify user 'test-user-123' Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): request wbcLogonUser succeeded Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): user 'test-user-123' granted access Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): Returned user was 'test-user-123' Jul 24 16:37:25 hlsfreeradius01 radiusd[2995]: pam_winbind(radiusd:auth): [pamh: 0x7f0bff4029c0] LEAVE: pam_sm_authenticate returning 0 (PAM_SUCCESS) Jul 24 16:37:25 hlsfreeradius01 audit[2995]: <audit-1100> pid=2995 uid=0 auid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_winbind acct="test-user-123" exe="/usr/sbin/radiusd" hostname=? addr=? terminal=pts/1 res=success' Jul 24 16:37:25 hlsfreeradius01 audit[2995]: <audit-1101> pid=2995 uid=0 auid=0 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=? acct="test-user-123" exe="/usr/sbin/radiusd" hostname=? addr=? terminal=pts/1 res=failed' ----------------------- Specific radiusd -XXX log output showing the PAM user authentication rejected: ----------------------- Received Access-Request Id 172 from 127.0.0.1:55300 to 127.0.0.1:1812 length 78 User-Name = 'test-user-123' User-Password = 'test-password' NAS-IP-Address = 10.101.1.8 NAS-Port = 1812 Message-Authenticator = 0x82a2d0ae5c2192628b6263c968890117 Fri Jul 24 16:37:25 2015 : Debug: (0) Received Access-Request packet from host 127.0.0.1 port 55300, id=172, length=78 Fri Jul 24 16:37:25 2015 : Debug: (0) User-Name = 'test-user-123' Fri Jul 24 16:37:25 2015 : Debug: (0) User-Password = 'test-password' Fri Jul 24 16:37:25 2015 : Debug: (0) NAS-IP-Address = 10.101.1.8 Fri Jul 24 16:37:25 2015 : Debug: (0) NAS-Port = 1812 Fri Jul 24 16:37:25 2015 : Debug: (0) Message-Authenticator = 0x82a2d0ae5c2192628b6263c968890117 Fri Jul 24 16:37:25 2015 : Debug: (0) # Executing section authorize from file /etc/raddb/sites-enabled/default Fri Jul 24 16:37:25 2015 : Debug: (0) authorize { Fri Jul 24 16:37:25 2015 : Debug: (0) filter_username filter_username { Fri Jul 24 16:37:25 2015 : Debug: (0) if (!&User-Name) Fri Jul 24 16:37:25 2015 : Debug: (0) if (!&User-Name) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ / /) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ / /) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /@.*@/ ) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /@.*@/ ) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /\\.\\./ ) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /\\.\\./ ) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\\.(.+)$/)) Fri Jul 24 16:37:25 2015 : Debug: (0) if ((&User-Name =~ /@/) && (&User-Name !~ /(a)(.+)\\.(.+)$/)) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /\\.$/) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /\\.$/) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /(a)\\./) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&User-Name =~ /(a)\\./) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) } # filter_username filter_username = notfound Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling preprocess (rlm_preprocess) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from preprocess (rlm_preprocess) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [preprocess] = ok Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling chap (rlm_chap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from chap (rlm_chap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [chap] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling mschap (rlm_mschap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from mschap (rlm_mschap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [mschap] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling suffix (rlm_realm) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) suffix : Checking for suffix after "@" Fri Jul 24 16:37:25 2015 : Debug: (0) suffix : No '@' in User-Name = "test-user-123", looking up realm NULL Fri Jul 24 16:37:25 2015 : Debug: (0) suffix : No such realm "NULL" Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from suffix (rlm_realm) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [suffix] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling eap (rlm_eap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) eap : No EAP-Message, not doing EAP Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from eap (rlm_eap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [eap] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling files (rlm_files) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) files : users: Matched entry DEFAULT at line 182 Fri Jul 24 16:37:25 2015 : Debug: (0) files : ::: FROM 0 TO 0 MAX 0 Fri Jul 24 16:37:25 2015 : Debug: (0) files : ::: TO in 0 out 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from files (rlm_files) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [files] = ok Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling expiration (rlm_expiration) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from expiration (rlm_expiration) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [expiration] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling logintime (rlm_logintime) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from logintime (rlm_logintime) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [logintime] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: calling pap (rlm_pap) for request 0 Fri Jul 24 16:37:25 2015 : WARNING: (0) pap : No "known good" password found for the user. Not setting Auth-Type Fri Jul 24 16:37:25 2015 : WARNING: (0) pap : Authentication will fail unless a "known good" password is available Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authorize]: returned from pap (rlm_pap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [pap] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) } # authorize = ok #PAM authentication sequence begins Fri Jul 24 16:37:25 2015 : Debug: (0) Found Auth-Type = PAM Fri Jul 24 16:37:25 2015 : Debug: (0) # Executing group from file /etc/raddb/sites-enabled/default Fri Jul 24 16:37:25 2015 : Debug: (0) authenticate { Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authenticate]: calling pam (rlm_pam) for request 0 Fri Jul 24 16:37:25 2015 : Debug: pam_pass: using pamauth string <radiusd> for pam.conf lookup Fri Jul 24 16:37:25 2015 : Debug: pam_pass: function pam_acct_mgmt FAILED for <test-user-123>. Reason: Authentication failure Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[authenticate]: returned from pam (rlm_pam) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [pam] = reject Fri Jul 24 16:37:25 2015 : Debug: (0) } # authenticate = reject Fri Jul 24 16:37:25 2015 : Debug: (0) Failed to authenticate the user Fri Jul 24 16:37:25 2015 : Auth: (0) Login incorrect: [test-user-123/test-password] (from client localhost port 1812) Fri Jul 24 16:37:25 2015 : Debug: (0) Using Post-Auth-Type Reject Fri Jul 24 16:37:25 2015 : Debug: (0) # Executing group from file /etc/raddb/sites-enabled/default Fri Jul 24 16:37:25 2015 : Debug: (0) Post-Auth-Type REJECT { Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: calling attr_filter.access_reject (rlm_attr_filter) for request 0 Fri Jul 24 16:37:25 2015 : Debug: %{User-Name} Fri Jul 24 16:37:25 2015 : Debug: Parsed xlat tree: Fri Jul 24 16:37:25 2015 : Debug: attribute --> User-Name Fri Jul 24 16:37:25 2015 : Debug: (0) attr_filter.access_reject : EXPAND %{User-Name} Fri Jul 24 16:37:25 2015 : Debug: (0) attr_filter.access_reject : --> test-user-123 Fri Jul 24 16:37:25 2015 : Debug: (0) attr_filter.access_reject : Matched entry DEFAULT at line 11 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: returned from attr_filter.access_reject (rlm_attr_filter) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [attr_filter.access_reject] = updated # Ends Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: calling eap (rlm_eap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) eap : Request didn't contain an EAP-Message, not inserting EAP-Failure Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: returned from eap (rlm_eap) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [eap] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) remove_reply_message_if_eap remove_reply_message_if_eap { Fri Jul 24 16:37:25 2015 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) Fri Jul 24 16:37:25 2015 : Debug: (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE Fri Jul 24 16:37:25 2015 : Debug: (0) else else { Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: calling noop (rlm_always) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) modsingle[post-auth]: returned from noop (rlm_always) for request 0 Fri Jul 24 16:37:25 2015 : Debug: (0) [noop] = noop Fri Jul 24 16:37:25 2015 : Debug: (0) } # else else = noop Fri Jul 24 16:37:25 2015 : Debug: (0) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop Fri Jul 24 16:37:25 2015 : Debug: (0) } # Post-Auth-Type REJECT = updated Fri Jul 24 16:37:25 2015 : Debug: (0) Delaying response for 1 seconds Fri Jul 24 16:37:25 2015 : Debug: Waking up in 0.2 seconds. Fri Jul 24 16:37:26 2015 : Debug: Waking up in 0.7 seconds. Fri Jul 24 16:37:26 2015 : Debug: (0) Sending delayed response Fri Jul 24 16:37:26 2015 : Debug: (0) Sending Access-Reject packet to host 127.0.0.1 port 55300, id=172, length=0 Sending Access-Reject Id 172 from 127.0.0.1:1812 to 127.0.0.1:55300 Fri Jul 24 16:37:26 2015 : Debug: Waking up in 3.9 seconds. Fri Jul 24 16:37:30 2015 : Debug: (0) Cleaning up request packet ID 172 with timestamp +26 Fri Jul 24 16:37:30 2015 : Info: Ready to process requests ---------------- Standard NTLM via AD works very well, but utilizing the PAM module is creating a whole new can of worms. My use case for PAM is 2 factor authentication with Google Authenticator, but if there is a better way to do this while still utilizing FreeRadius, then I am very interested. However, at this point I have not been unable to find another authentication methodology for Google OTP without the PAM component. If anyone is able to shed some light on the existing authentication issue I described, or even suggest a better way of doing this 2FA sequence in question, I would be extremely grateful. Also attaching the, radius -XXX startup output separately. Have a great weekend. -Josh

2 1