0€	*†H†÷ €0€10	`†He 0€	*†H†÷ €$€PContent-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: 8bit

‚ I turned on the insane debugging and got the following:
_________________________________________________________________________________________________________________
06/23/20 09:56:46 (fd:13) (pid:5857) (D_ALWAYS) read_password_from_filename():
read_secure_file(/etc/condor/password.d/POOL) failed!
06/23/20 09:56:46 (fd:13) (pid:5857) (D_PRIV) PRIV_CONDOR --> PRIV_ROOT at
/var/lib/condor/execute/slot3/dir_3977/userdir/.tmpEsbepJ/BUILD/condor-8.9.7/src/condor_utils/secure_file.cpp:213
06/23/20 09:56:46 (fd:13) (pid:5857) (D_PRIV) PRIV_ROOT --> PRIV_CONDOR at
/var/lib/condor/execute/slot3/dir_3977/userdir/.tmpEsbepJ/BUILD/condor-8.9.7/src/condor_utils/secure_file.cpp:216
06/23/20 09:56:46 (fd:13) (pid:5857) (D_ALWAYS:2) ERROR:
read_secure_file(/etc/condor/password.d/POOL): open() failed: No such file or
directory (errno: 2)
06/23/20 09:56:46 (fd:13) (pid:5857) (D_ALWAYS) read_password_from_filename():
read_secure_file(/etc/condor/password.d/POOL) failed!
06/23/20 09:56:46 (fd:13) (pid:5857) (D_SECURITY) PW: Server sending.
06/23/20 09:56:46 (fd:13) (pid:5857) (D_SECURITY) In server_send: -1.
06/23/20 09:56:46 (fd:13) (pid:5857) (D_SECURITY) Server send '', '', 0 0 0
__________________________________________________________________________________________________________________

No symlinks in the hierarchy, everything owned by root:root with exec
permissions all the way down. I believe I am starting the daemons as root? It
looks like the privilege escalation is going fine based on what the log shows
here. At least I have something to go off of now, but at first glance I don't
understand why open() would fail with code 2 on that file. I double checked
with a python interactive shell as root and I was able to open and spit out
bytes from that file just fine.

My thinking is that maybe I am not starting condor correctly, so it can't try
to open the file as root? I am on CentOS7, and started condor with 'sudo
systemctl start condor'.

I also double-checked my security config, and the only differences between my 
config file and the readthedocs are:
______________________________
ALLOW_DAEMON = *
ALLOW_NEGOTIATOR = *
______________________________

Which I do not think are relevant to this issue. Does anyone have any more 
ideas on things I could check to see what's going on?

-Wes

Wesley Taylor â€“ Cluster Manager
Numerica Corporation (www.numerica.us)
5042 Technology Parkway #100
Fort Collins, Colorado 80528
â˜Žï¸ (970) 207 2232
ðŸ“§ wesley.taylor@numerica.us


-----Original Message-----
From: HTCondor-users <htcondor-users-bounces@cs.wisc.edu> On Behalf Of Zach
Miller
Sent: Tuesday, June 23, 2020 9:30 AM
To: HTCondor-Users Mail List <htcondor-users@cs.wisc.edu>
Subject: Re: [HTCondor-users] [External] - Re: Debugging HTCondor
Authentication Errors

CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.


Hello,

You might also check the permissions and ownership on the parent directories.
read_secure_file() wants to make sure the file couldn't have been tampered
with.

Are there symlinks in the directory hierarchy?

You are starting the daemons as root?

You can turn on more (insane) debugging by setting "COLLECTOR_DEBUG =
D_ALL:2".  It is A LOT, but that will get you every message.  You may also
need to increase the size of the log if it rotates too quickly
(MAX_COLLECTOR_LOG).

Looking at the code, though, read_secure_file() should already be logging why
it failed even without changing the debug level.  Is there anything earlier in
the log that gives a hint?  (Feel free to send the whole log offline if you'd
like).


Cheers,
-zach


ï»¿On 6/23/20, 10:20 AM, "HTCondor-users on behalf of wesley.taylor@numerica.us"
<htcondor-users-bounces@cs.wisc.edu on behalf of wesley.taylor@numerica.us>
wrote:

    Hi Zach!

    Thanks for that explanation, I was obviously looking in the wrong
direction there. I changed the permis‚ sions like you said, but I am still
getting the same error from my collector about reading the file. Is there a
debug setting I can add to get it to tell me more about why the
read_secure_file call failed?

    -Wes

    Wesley Taylor â€“ Cluster Manager
    Numerica Corporation
(https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.numerica.us%2F&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=5XBBEpxWZ2gmgtKwtxy0ckfEkCFKyqo7EbkP13MRhMw%3D&amp;reserved=0)
    5042 Technology Parkway #100
    Fort Collins, Colorado 80528
    â˜Žï¸ (970) 207 2232
    ðŸ“§ wesley.taylor@numerica.us


    -----Original Message-----
    From: HTCondor-users <htcondor-users-bounces@cs.wisc.edu> On Behalf Of
Zach Miller
    Sent: Monday, June 22, 2020 10:02 PM
    To: HTCondor-Users Mail List <htcondor-users@cs.wisc.edu>
    Subject: [External] - Re: [HTCondor-users] Debugging HTCondor
Authentication Errors

    CAUTION: This email originated from outside of the organization. Do not
click links or open attachments unless you recognize the sender and know the
content is safe.


    Hi Wes,

    (First, no problem sending email any time you have a question!)

    You wrote:
    > It looks like for some reason condor can't read the POOL file, even
    > though the file (and its parent directory) are owned by the user and
    > group condor:condor, and everyone has execute permissions on /etc and
    > /etc/condor. I also made selinux permissive just in case that was the
    > issue.

    Clearly the error message here should be better.  When HTCondor says,
"read_secure_file(/etc/condor/password.d/POOL) failed!", in this case it's not
because it couldn't read the file but that the file was TOO permissive.

    The file for PASSWORD authentication should be chmod 600 and owned by
root:root.  Try fixing that and let us know if that did the trick.


    Cheers,
    -zach



    On 6/22/20, 7:11 PM, "HTCondor-users on behalf of
wesley.taylor@numerica.us" <htcondor-users-bounces@cs.wisc.edu on behalf of
wesley.taylor@numerica.us> wrote:

        Hello,

        I feel a little bad for emailing everyone twice in the same day, but I
am still getting familiar with HTCondor.

        I tested a minicondor last week and was having a ball of a time, but
now I am looking to scale up and have hit some hiccups. I am following the
"Setting up an HTCondor Pool"
(https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Fhtcondor.readthedocs.io%2Fen%2Flatest%2Fadmin-manual%2Fquick-start-condor-pool.html&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=YX2xTyQwlSlmcAdvjcvKig%2BsyHxijnD%2BVE0d4QWWMhI%3D&amp;reserved=0)
but with some minor modifications to try and make the test setup better match
the production system's architecture. I simply changed the configuration so
one machine had the roles of "Submit" and "Central Manager" and I have two
"Execute" machines located on the same network.

        I went through the guide, but when I started everything up they
weren't authenticating with one another. On both the "Execute" machines I am
getting the following from my StartLog (I set STARTD_DEBUG  = D_SECURITY:2 in
my config):

        __________________________________________________________________________________________________________________________________________________________________________________________________
        06/22/20 17:33:14 SECMAN: new session, doing initial authentication.
        06/22/20 17:33:14 SECMAN: authenticating RIGHT NOW.
        06/22/20 17:33:14 SECMAN: AuthMethodsList: PASSWORD
        06/22/20 17:33:14 SECMAN: Auth methods: PASSWORD
        06/22/20 17:33:14 AUTHENTICATE: setting timeout for
<192.168.0.69:9618> to 20.
        06/22/20 17:33:14 AUTHENTICATE: in authenticate( addr ==
'<192.168.0.69:9618>', methods == 'PASSWORD')
        06/22/20 17:33:14 AUTHE‚ NTICATE: can still try these methods: PASSWORD
        06/22/20 17:33:14 HANDSHAKE: in handshake(my_methods = 'PASSWORD')
        06/22/20 17:33:14 HANDSHAKE: handshake() - i am the client
        06/22/20 17:33:14 HANDSHAKE: sending (methods == 512) to server
        06/22/20 17:33:14 HANDSHAKE: server replied (method = 512)
        06/22/20 17:33:14 AUTHENTICATE: will try to use 512 (PASSWORD)
        06/22/20 17:33:14 AUTHENTICATE: do_authenticate is 1.
        06/22/20 17:33:14 PW.
        06/22/20 17:33:14 PW: getting name.
        06/22/20 17:33:14 PW: Generating ra.
        06/22/20 17:33:14 PW: Client sending.
        06/22/20 17:33:14 Client sending: 0, 19(condor_pool@worker1), 256
        06/22/20 17:33:14 PW: Client receiving.
        06/22/20 17:33:14 Server sent status indicating not OK.
        06/22/20 17:33:14 PW: Client received ERROR from server, propagating
        06/22/20 17:33:14 PW: CLient sending two.
        06/22/20 17:33:14 In client_send_two.
        06/22/20 17:33:14 Can't send null for random string.
        06/22/20 17:33:14 Client sending: 0() 0 0
        06/22/20 17:33:14 Sent ok.
        06/22/20 17:33:14 AUTHENTICATE: method 512 (PASSWORD) failed.
        06/22/20 17:33:14 AUTHENTICATE: can still try these methods:
        06/22/20 17:33:14 HANDSHAKE: in handshake(my_methods = '')
        06/22/20 17:33:14 HANDSHAKE: handshake() - i am the client
        06/22/20 17:33:14 HANDSHAKE: sending (methods == 0) to server
        06/22/20 17:33:14 HANDSHAKE: server replied (method = 0)
        06/22/20 17:33:14 AUTHENTICATE: no available authentication methods
succeeded!
        06/22/20 17:33:14 SECMAN: required authentication with collector
192.168.0.69 failed, so aborting command DC_START_TOKEN_REQUEST.
        06/22/20 17:33:14 Failed to request a new token: DAEMON:1:failed to
start command for token request with remote daemon at
'<192.168.0.69:9618>'.|AUTHENTICATE:1003:Failed to authenticate with any
method|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
        __________________________________________________________________________________________________________________________________________________________________________________________________


        So then I went and looked at the CollectorLog on the Manager:
        __________________________________________________________________________________________________________________________________________________________________________________________________
        06/22/20 18:03:15 DC_AUTHENTICATE: required authentication of
192.168.0.70 failed: AUTHENTICATE:1003:Failed to authenticate with any
method|AUTHENTICATE:1004:Failed to authenticate using PASSWORD
        06/22/20 18:03:15 read_password_from_filename():
read_secure_file(/etc/condor/password.d/POOL) failed!
        06/22/20 18:03:15 read_password_from_filename():
read_secure_file(/etc/condor/password.d/POOL) failed!
        ___________________________________________________________________________________________________________________________________________________________________________________________________

        (Don't pay attention to the fact the timestamps are really far apart,
I have just been trying some more things in the past little bit)

        It looks like for some reason condor can't read the POOL file, even
though the file (and its parent directory) are owned by the user and group
condor:condor, and everyone has execute permissions on /etc and /etc/condor. I
also made selinux permissive just in case that was the issue.

        Does anyone have any further steps I can take to figure out why this
read is failing?

        Thank you!
        -Wes


        Wesley Taylor â€“ Cluster Manager
        Numerica Corporation
(https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fwww.numerica.us%2F&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=5XBBEpxWZ2gmgtKwtxy0ckfEkCFKyqo7EbkP13MR‚´hMw%3D&amp;reserved=0)
        5042 Technology Parkway #100
        Fort Collins, Colorado 80528
        â˜Žï¸ (970) 207 2232
        ðŸ“§ wesley.taylor@numerica.us




    _______________________________________________
    HTCondor-users mailing list
    To unsubscribe, send a message to htcondor-users-request@cs.wisc.edu with
a
    subject: Unsubscribe
    You can also unsubscribe by visiting
    https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.cs.wisc.edu%2Fmailman%2Flistinfo%2Fhtcondor-users&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=1kQ1hN%2FIorjiWT7JRHXPodEiLznW6ycKXgqUH%2B9tOHo%3D&amp;reserved=0

    The archives can be found at:
    https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.cs.wisc.edu%2Farchive%2Fhtcondor-users%2F&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=Wh6oeUE1WLnH2MTYVV8ND2u3uB%2F1i9wUyI8DIxKf%2FIE%3D&amp;reserved=0


_______________________________________________
HTCondor-users mailing list
To unsubscribe, send a message to htcondor-users-request@cs.wisc.edu with a
subject: Unsubscribe
You can also unsubscribe by visiting
https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.cs.wisc.edu%2Fmailman%2Flistinfo%2Fhtcondor-users&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=1kQ1hN%2FIorjiWT7JRHXPodEiLznW6ycKXgqUH%2B9tOHo%3D&amp;reserved=0

The archives can be found at:
https://usg02.safelinks.protection.office365.us/?url=https%3A%2F%2Flists.cs.wisc.edu%2Farchive%2Fhtcondor-users%2F&amp;data=02%7C01%7C%7Cde9e15f0f6384ad5e08208d8178ab928%7Cfae7a2aedf1d444e91bebabb0900b9c2%7C0%7C0%7C637285231872717967&amp;sdata=Wh6oeUE1WLnH2MTYVV8ND2u3uB%2F1i9wUyI8DIxKf%2FIE%3D&amp;reserved=0
       ‚þ0‚©0‚‘ Ù7ä‡O ´K´‚ÉHÄÝ0	*†H†÷ 0[10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-GILGALAD-CA0160724195713Z360724200712Z0[10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-GILGALAD-CA0‚"0	*†H†÷ ‚ 0‚
‚ ªûÿwä£ësÇ%Æº»êNÆ®µE»àPŸÊµ¢pcÙ°â›%÷(–vãèC%?—Û¦ÿÃj[ç.ëôØé‡ëm‹ùKSÕ‚ü«t‘Rûq;Y7åJü#p5[PêxV5«KLÍ×(X\j¬†E‰×êîJÃ°kIÿ8g{Ã«ýyMgBZrûusQÆþ8©?œ7“9•“Îp{wº°ÄT‘ ¼Ùdçd¢‰Êvfì‰GêBO•]a•â
U@«‹ãßÔ @Ò
¿@Æ<ƒøµp†\…2-£–pæZ¢Y=$7~¤¿/Ü³#\Â6
™Aá¦dƒ.A&°å-6˜œ‰¢×CN×ìX­åD†¼Wb	¼6W`'q.ÉKâ­1æd—{gÜo^@	iÞZ1Ö !HÍ»ÿ§Á©v(Ãõ|…öaomiÏ%Ï¨ËÿÖbàPŠ«ûác—¬Ê3™˜fáåš»]ùâàƒµlŒ;ápÌ]Bxîú<É~\e™ŠKy–Ë»¾*¦C*•RqÅhK×^Òà‘9ÎhÖ]DÇ^xºÑ¢>±=Y\#9ˆg=ðdDqž& qåÝd]ïœ¾)0Ô?†f¡âk!ŽÜŽÿ¨Ç5ïe»$ÒáJÿê
Ty«Ë¬Ô; £i0g0	+‚7 C A0Uÿ†0Uÿ0ÿ0Uà‹1ÞfOzTRz!ª{.Ž¡0	+‚7 0	*†H†÷ ‚ '0 »gù!TÇæ¬°…cá¡‡Œ®mwaÑê&y<«0¯¡9/fKm•„“WÜ 	™x$dÀ†öâþ¹¯÷b¦@MþZV'3ü€G^ø8ïæßU¥¼sÝÀdÓSEÿ7?‚ÇHnæƒÊÜÒØ‚‚ÝÞtÀ_(E+þÚêwë£“[½£ðF_¼%G‘7CêöQøTa¤ôaBÿ	^öT¡f%ÁŠ,ª¼ÄoYy ôÆMéQ‚9«Çûýó"$¥:…¿eúÕÏîàËX†°ƒó(QÍÀáÉqdô¶a‘…˜§6Úa3Ø–"x>ËÄc«â³Ù…éŸéëî½¶/¹ý›F)zzæn…ÂPï6ÒÚ-Œý”Èw3{l0ÿ×Îy²›øËÌ¸æîK<•pð¤_ÊªxæÔL¢@‡'óÏr3MýSºÚ%áéº,#»oØ;©+êe-d3ºeêþ‹ËöJ ,}·òOŠÝV—™Va´—ÇÉv)íX£_zFCM¸€¨Í·Ë{€(œnlúº.š§ŠÉð––%—Q@ÄD&Àÿú÷®²îâkºÚÑU#vš[f5!t¥ÕôñWìjÄ™ÛHg	¢Ö;V÷‹FN°@ ÜÞ
ou.ƒ èr&qÇgã¢&˜À$£JôÃ˜|Ò·Âk¾ÿ0‚œ0‚„ o   Aa
®7ŠÎN¨     A0	*†H†÷ 0[10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-GILGALAD-CA0190722141801Z210722142801Z0\10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-CELEBRIAN-CA0‚"0	*†H†÷ ‚ 0‚
‚ ¤K‚84È-Ú2ðL" WüÄOÏÍég@£¹´#ô—tÛ¥PI#Å¨¹Z®w‹A!YRéQOcxè]¬xë ŒªRtBc&ËÈP×é«üµT¹q4´Ùt‹£ìÝ°¬Ê(ŠÒÝÒCÓ4ôdIaj	Ÿä°…ÕŽ1H® Ç]Ö Äb—Éúo`œ.Vs«…µÜŠoðR ;ÖíôÑŸy#Ž'bæGCê¿%3“ÚHù™²^Ot¢ºøMXê°B¼„îÐÀhå8îÂÞ\¢MÕ{@JäX<õ¢ÛúÌ‰É¶Ò¡ºº±.ÞGI¡<ï|(‚3‡‹¬º@•d»ƒï&¦ÑÏ £‚V0‚R0	+‚70#	+‚7¯å559ðæ}îÖ#¶ËàGAy;10U¡ã2¨bÈ À“|Íºû¥à³ë0	+‚7
 S u b C A0Uÿ†0Uÿ0ÿ0U#0€à‹1ÞfOzTRz!ª{.Ž¡0ÓUË0È0Å Â ¿†¼ldap:///CN=ad-GILGALAD-CA,CN=Gilgalad,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=numerica,DC=us?certificateRevocationList?base?objectClass=cRLDistributionPoint0Æ+¹0¶0³+0†¦ldap:///CN=ad-GILGALAD-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=numerica,DC=us?cACertificate?base?objectClass=certificationAuthority0	*†H†÷ ‚ fF„¥=ï¾“»l “¯«O´tÒ:ÊN 8˜âc/ÓS4±=iaèÀºöRªb †f^öýóÑ=ž\‘¨×³,õË’öGÕè=$G"­™‹Ó 'ÿHd‘\Ÿê5‰¤"¦¾ñÓÔ¦wÊ³¿c¿–)@8BÙäEŠóyÐxH’(Y'«ŒÝóX!˜ß1ÕBk¹¯æ›S£çúAä‰c¢}Mÿüå’YiIIG×‘öÓ=›á²vÍŸ–¾~™”úf	¶éò¢œì÷V†Ÿ:†Ç«7Ò7×³ö1k­:¢…{zgÈB ,HZ¥ÞæÄ™±(} FíLyV­-†GÀ¬¬±Àøº/(%2·mPAëõ@ÁÆ-ˆ¿n¦Õ AeU¸žÿÉÈ¥° fÀ„l³dÕ¨x{3±A´ Ëºed1šÞ 1?ìÛè“Ï:9a§)­2ŽxÏS`“ò£ær’øÅHÇf
 ;+lp¸ …K¼¦±ÆÕçwKG&jvRôïû­þÒÍMuÞãÃä,8*¡l¹ºÔInß@-=/áE°o·,Pd¨ì uÆbwÿ #œPrG++ÂjÞï+œ)h[{ƒÃÎ¡Ã³3æ#šQu„q¤™¡)SÓè	®~–±%HwÊ·	*“}Ë}Ì[WYû„µ‡®Ì…0‚­0‚• '  	1¬6F;GdU   	0	*†H†÷ 0\10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-CELEBRIAN-CA0200512150942Z210722142801Z0Á10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10UNumerica10UUsers10UPresent Interns10UWesley Taylor1(0&	*†H†÷	wesley.taylor@numerica.us0‚"0	*†H†÷ ‚ 0‚
‚ åÉC-ªW’"Õ^?Ñ‰¿âI’ßœiÌ¯Y¥ýÄKê1Î]¾Ì¨îD‘<\óÅ¥üáhn0Ç9ÏR5B©ÔÚÙ!óø¨›âGßÇÚëtãð{?ÞéÔoz<fó+Þec/º¼AD 2	ñÒ”ˆä,–Æ4TÑÇ/ããe¾~lÅÕ²5¿Þ¨Ï¦ÁÔî^3±NóúW~3&ËÜ`¢TÎCò2;ÚŽ Ú"­9Z1TÇæçJÐýŠ¿0úBßÁÃ¥svÓ½n#Ÿ9Ægˆ®2 ‰ðã*ç9²Ø9§\U+Œ	d[Òð/pÁ/›žÚò«íƒ³48Ÿ™ÕL»M £‚ 0‚ü0<	+‚7/0-%+‚7÷ðl³Œ…¹„žª‡á€_%‚ê¢DÈÄ"e(0U%0
+0Uÿ 0	+‚7
00
+0D	*†H†÷	7050*†H†÷ €0*†H†÷ €0+0
*†H†÷0U6G <(8 ù»:Eÿ`œe' ]bæ0U#0€¡ã2¨bÈ À“|Íºû¥à³ë0ÕUÍ0Ê0Ç Ä Á†¾ldap:///CN=ad-CELEBRIAN-CA,CN=Celebrian,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=numerica,DC=us?certificateRevocationList?base?objectClass=cRLDistributionPoint0Ç+º0·0´+0†§ldap:///CN=ad-CELEBRIAN-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ad,DC=numerica,DC=us?cACertificate?base?objectClass=certificationAuthority0RUK0I ,
+‚7 wesley.taylor@ad.numerica.uswesley.taylor@numerica.us0	*†H†÷ ‚ _|Å† ØSëÐj‰†,¬È/KîyíR69 áŸÉœÒS :h€âªµ&,x…—>ƒ¿ßNžHe ÞôzµÛ"=šæèA À`î¢®úÁ÷Fß—„”† Ã.vB¹¸ÿœS5«$æŸöŠQ&q½)=•lH&Cý‘yõ¼—pBÆÝYé
üi™÷ëùÔ¶d‰Üë
rlK/i½äÌJ%éšy)]“€'¯Ë–e½Øž¥ÈðW~¹L: 8sæGëa½CÂ†“ò„ãâÎi·Qä¥2»É@„ùÁyÁÆ‘‰ë?7ìÆñ1R§KU³ÖµmžÌ1‚!0‚0s0\10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-CELEBRIAN-CA'  	1¬6F;GdU   	0	`†He  ‚0	*†H†÷	1	*†H†÷0	*†H†÷	1200623165619Z0O	*†H†÷	1B@G~Q_]±‹¶K¨º¹‘^X»Ø–%(rø:žnì¶9 z&œ‡^‘]Iy¤—r±(ä¼Ž.Q¡GÉŽšù*ç|0R*†H†÷	1C0A       |ißÐxgJ«ä§	F]ç    € 00wesley.taylor@numerica.us0‚	+‚71u0s0\10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-CELEBRIAN-CA'  	1¬6F;GdU   	0„*†H†÷	1u s0\10
	’&‰“ò,dus10
	’&‰“ò,dnumerica10
	’&‰“ò,dad10Uad-CELEBRIAN-CA'  	1¬6F;GdU   	0“	*†H†÷	1…0‚0	`†He*0	`†He0
*†H†÷0	`†He0*†H†÷ €0*†H†÷@0	`†He0	`†He0	`†He0+0	*†H†÷ ‚ Ÿ2¡Œ hàK-c›Â±NÈi‹Mà³‹7ñ¿Âó:å[AåŠ\ä-àR
9K Ç”A Úñq¯ Èh¬ôTGcñ½8’)åõ˜*6Jy¿Ý6ËÈÜð¾6õG¬ö	ó…•šR±‚Døî
èºº{²¿Q(Œ‡W!Rk^	Â}FŸåSƒÁ‘_áÔ(Z¾ç…œ
Ô7b°™í§OØÍZGnùx¡5SŽ[«£|µ5¶ÜÎagTÈO&Ç>gŸÅòl„îå“|JvúÈQã¸ÞüQÉwª$!4˜Ä5Ýä,ÚEÍÖŒv}=aõdëñ,“{÷ï      