If you try to P2V a Windows 8 OEM machine You're gonna have a bad time.

I won’t get into the Holy War that is choosing the right virtualization environment for you. All I’ll say is that virtualization is GREAT, and it can make certain things much easier for you!

About the time I was going to write this blog post, I came across this article: http://justaskweg.com/?p=1093. I wish I had found it sooner because it explains (in great detail) some of the things I’m about to write about here.

Here’s the basics: OEM manufacturers seem to like using GPT partition tables on machines these days because it allows them to create multiple (proprietary) partitions, at least one of which is probably a recovery partition for the Windows operating system installed on it.

What’s the problem with this? Well, most virtualization software that I am aware of at the time of this writing do not directly support booting to a GPT partition table without some editing.

In short, you’ll probably have to convert your GPT partitioned drive to an MBR drive

There are plenty of ways to go about this, but I’ll give an overview of the way I used because I prefer VirtualBox.

  1. Get an image of the computer you want to P2V
    • I like Disk2Vhd because it lets you create a hot-image that VirtualBox can use right away
  2. Create a VM
  3. Mount your VHD
  4. Optionally mount another drive to copy partitions to (unless you have a reliable way to convert from GPT to MBR on the same drive)
  5. Boot to a tool like GParted LiveCD to perform these partition changes
  6. Mount a Windows 8 repair disk
  7. Let it try to repair automatically
  8. If automatic repair doesn’t work, use bootrec /fixboot and bootrec /fixmbr

Yes, you will probably have to get rid of some of the extra manufacturer partitions they create, you may also have to fiddle with the type of controller you have your hard drive attached to. I’ve seen various articles reporting more or less success with IDE/SATA/SAS.

Best of luck to you!

So you’ve been using JIRA, it’s going well – and now you want to move away from the default internal directory or the built-in LDAP support. This may be because you’ve outgrown it, because you want easier sign-on, or because there’s been a shift in the environment that you’re supporting. No matter what, you’re about to go on a ride.

JIRA supports Seraph authentication – both are from Atlassian. The great thing about this is it will allow you to write your own authenticator class in Java. The bad part about this is it’s very poorly documented.

Your first search will probably land you here: https://docs.atlassian.com/atlassian-seraph/latest/sso.html

At the time of this writing, that article is over a year old and it doesn’t get you quite where you need to go. Furthermore, it doesn’t even tell you where to get started.

As you search around more, you’ll find various Confluence articles at Atlassian, a few GitHub projects, and some questions on answers.atlassian.com. I’m going to try to save you some of the effort by giving the details of what I did to get an authenticator up and running.

As a note – my environement is Windows based so your steps may vary accordingly.

Here’s a brief overview:

  1. Download the SDK: https://developer.atlassian.com/display/DOCS/Set+up+the+Atlassian+Plugin+SDK+and+Build+a+Project
  2. Don’t worry about getting the Eclipse editor – you can get by with a simple editor like Notepad++ for this.
  3. After you’ve installed the Atlassian SDK, don’t use it for anything but building!

I saw a few different (misleading) posts on how to build the authenticator. The bottom line is that using atlas-create-jira-plugin command doesn’t work, and nor does atlas-create-jira-plugin-module.

It seems that this authenticator is some strange mix in-between. It’s a type 1 plugin which means it has to be “installed” (copied) into the WEB-INF/lib

Let’s get started…

The first thing the documentation tells you to do is implement the com.atlassian.seraph.auth.DefaultAuthenticator; class. I’ve found this to have issues, and had much better success with: com.atlassian.jira.security.login.JiraSeraphAuthenticator.

See my BitBucket project for my quick implementation of this class with very limited features: https://bitbucket.org/docsaintly/jira-sso-with-siteminder.

From here, you just have to implement: public Principal getUser(HttpServletRequest request, HttpServletResponse response)

This function returns a Principal object which is basically just the username of the person who is authenticated. You can use the super.getUser(request,response) to do this for you without much work.

The rest is up to you and how you want to choose what to do. As you can see in my implementation, I look for the variable “username” in my header that I’ve been passed from SiteMinder. If you use a different variable, just change this.

From here, I have to strip off the domain name that is passed along with the username. I could have also retrieved the cookie itself because that contains the username without the domain. It’s all up to you what you want to do. You can find other examples online that go as far as to automatically create new users in the system after they’ve been authenticated through the SSO. This is where you get to determine how it figures out which user in JIRA gets mapped to the user coming from the SSO.

Once you have your code written, you can drop into the command prompt and run atlas-package assuming you have the Atlassian SDK installed.

This will alert you of any errors, and once it is successful you can copy your compiled .jar file to the WEB-INF/lib folder of your JIRA installation.

The one thing left to do is configure your seraph-config.xml file according to Atlassian’s SSO documentation to configure where the login and logout of Seraph will point.

After you’ve done all this, restart your JIRA instance and watch the atlassian-jira.log as it starts up to see if your authenticator loaded properly.

There are a few other things I’ve done that weren’t documented, but I haven’t confirmed if they are necessary.

With the way I’ve written the authenticator, if you authenticate through SiteMinder and land on the system but don’t have an account – you’ll be faced with the login page. You probably don’t want this – so you’ll want to disable the login gadget in the jpm.xml file according to this post: https://answers.atlassian.com/questions/296109/disable-jira-login-page-with-seraph-sso

The final thing is to set up some filters in Tomcat’s web.xml file to point certain activities towards Seraph’s Login and Security pages. This is the part I know the least about and will do more investigation on:

<!-- Seraph Filters for SiteMinder SSO -->
<filter>
<filter-name>login</filter-name>
<filter-class>com.atlassian.seraph.filter.LoginFilter</filter-class>
</filter>

<filter>
<filter-name>security</filter-name>
<filter-class>com.atlassian.seraph.filter.SecurityFilter</filter-class>
</filter>

<!-- Seraph Filter Mapping for SiteMinder SSO -->
<filter-mapping>
<filter-name>login</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>security</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Credits for this post go to MANY people who have provided snippets of code and help for a portion of JIRA/Seraph that is very poorly documented. I will try to add more credits as I polish this article.