Novell SecureLogin 7 and Securing Sensitive Authentication Information

 

Single sign-on, or SSO, is a type of access control for software systems to use to authenticate users’ credentials when accessing secure systems. SSO helps reduce password phishing and password fatigue by allowing the users to only enter their password once. This extra form of authentication also supports conventional authentication like Windows Credentials, and allows a company using SSO to reduce the costs of IT help desk calls regarding forgotten passwords. There are many vendors out in the marketplace for Single Sign-on software, but one that is exceptional and easy to integrate into most Windows based systems is Novell SecureLogin 7.

Novell SecureLogin 7 supports eDirectory, Active Directory, ADAM Directory, and other LDAP v3 directories, and also has a web wizard to enable SSO for websites. All SSO data can be backed up and restored using Novell SecureLogin making it much easier to maintain and secure user credentials.  Many companies today are using smart-card access for door entry as well as computer access to help with security of important information. SecureLogin also offers support for smart-cards, biometric software, and integrates well with Card Management Systems.

Novell SecureLogin provides the highest standard of security and protection by using Triple DES (Data Encryption Standard) and AES (Advanced Encryption Standard) algorithms for the encryption of sensitive user data. The software can even capture an audit trail of SSO activity in Novell Sentinel so the events can be viewed through Windows Event Viewer. Also, implementation of SSO no longer requires administrators to learn complex scripting languages to implement SSO functionality, with SecureLogin, the wizard will automatically generate the scripting for them. This will decrease the amount of time it normally takes to enable a mixed-infrastructure from weeks to mere days.

A favorite success story for Novell SecureLogin involves a medical group based out of central Florida. In this success story, which can be read here, the medical group deployed Novell SecureLogin and Novell Modular Authentication Service to help safeguard electronic medical records and help with lowering cost of support. They also integrated SSO with a fingerprint biometric solution to ensure maximum protection of the records being stored in their databases. Securing and maintaining sensitive information about patients and medical histories is important to any medical company, so having authentication software in place can help with strengthening security over access to records. Not only did integrating SSO help with maintaining security for the medical group, but it also helped with reducing their IT costs and improving employee productivity.

Attachmate acquired Novell in 2011. Since its acquisition, the Novell brand has had its products split distributed into four different companies. The identity, security and compliance products from Novell are now under the NetIQ brand name. Action Identity references these products as "NetIQ" products in place of its former name, "Novell." The products that are rebranded include Novell Compliance Management Platform, Novell Privileged User Manager, Novell Sentinel, Novell Secure Login, Novell Access Manager (Novell iChain) and Novell Identity Manager.

 

Action Identity will continue to be a preferred, Platinum Identity, Security and Compliance partner with Novell Identity Management products, even as they fall under the NetIQ brand name. NetIQ will continue to develop and provide excellent support around the Novell suite of identity, security and compliance products. Action Identity is here to answer any questions you have about NetIQ/Novell. We are able to support and offer services for existing Novell customers as well as guide those new and prospective NetIQ customers.

 

Look forward to more blogs in the future on the ease of integration of Novell SecureLogin as well as more success stories from companies utilizing Single Sign-on for their businesses. The security policies for systems, applications, and websites can be easily and quickly enforced with products like Novell SecureLogin.  

I hope you have enjoyed this blog. If you have any questions on this topic, leave a comment below and we’ll get back to you shortly. To learn more about Action Identity and Novell SecureLogin, visit our website. To contact us directly, please click here. We look forward to hearing from you.

Interested in learning more? Check out these entries: 

Novell Secure Login: A Premier Single Sign On Solution 

Novell Cloud Security Systems 

More Novell blog posts

The Necessity of Identity Management

Over the past couple months we have posted an influx of blogs, articles, videos, and reviews all discussing various facets of Identity Management. However we recognize that a simplistic overview of the essentials of Identity Management seems to be absent, and its intrinsic value is one that should not be missed due to confusion. It’s because of this need that we feel compelled to write this week’s blog post on the necessity of Identity Management, and break it down to its core values.

Identity Management is a powerful tool that can consolidate even the largest corporation.  With the rising amount of credentials that employees need to maintain, it is becoming increasingly difficult to keep track of user accounts for each application within an organization.  Studies have shown that employees (both past and present) pose a great threat to an organization; even more so if they leave on bad terms.  Several questions then arise:  What applications did this user have access to; how many user accounts did the user own; how is this data maintained; and lastly, who is responsible for removing or disabling the accounts?  For organizations without a central solution for dealing with a user’s application accounts, the time it takes to identify and remove these accounts can vary greatly, often leaving a window of vulnerability open.

That’s where Identity Management solutions come into play.  With Identity Management, administrators within an organization can control access to resources with the click of a button.

In a simple example, an organization has two resources where users exist:  The first is a directory service and the second is a database.  The directory service is used to authenticate users against machines they work on; it also grants them certain permissions based on their group membership within the directory.  The database is a billing system where users simply exist, but administrators can view and manipulate data regarding payments for employees.  Each of these resources requires their own user account for authentication, meaning the credentials can vary between the directory service and the billing database.  If a user joins this organization, who determines the username and password associated with the applications?  How are these two resources connected?  In our simple example, it is easy to maintain a list of users and their accounts by hand.  Now, throw in a mailing system, two terminal emulation applications, software for marketing, a help-desk solution, et cetera.  The list goes on as a company expands, and as this company grows, maintaining that list, which originally consisted of two applications, grows increasingly difficult.

With an Identity Management solution, the process of creating, maintaining, and removing accounts is completely centralized.  How is this accomplished?  An Identity Manager can connect to any resource within an organization using customized code, known as connectors.  These connectors allow the identity representing an employee from within the Identity Manager itself to be provisioned to target applications, connecting the IDM user object with the application user objects.  With an IDM (Identity Management) solution, administrators can standardize the naming of user accounts, based on the resource the user is being provisioned to.  For example, some applications may have a first initial/last name convention, while others have a first name/last name convention.  With an IDM, this customization can be supported while providing the necessary consolidation.

The process for provisioning varies drastically between resources, as each requires different information from the user in order to function properly, and the user-object within IDM is completely customizable to account this.

What if an account is created within an application, but not in the IDM?  The connectors can be configured to account for that.  Through the process known as reconciliation, IDM can actively scan for new accounts in an application and then add it to its own collective list of identities.  With both provisioning and reconciliation enabled, organizations can enjoy bidirectional synchronization from an Identity Management solution and its connected applications.  Organizations can also enforce unidirectional synchronization by disabling reconciliation or provisioning for certain applications, as they see fit.

One last feature, and probably one of its greatest features is the ability to allow users to request access to the connected resources.  By creating approval workflows, an organization can designate the IDM as their focal point for requesting access to resources.  Approval workflows can be enforced per resource to ensure that once a request is raised, designated approvers receive the information regarding the request and can approve or deny it accordingly.

An Identity Management solution is essential for companies that are experiencing problems with maintaining user accounts across applications.  It offers a single point of control that allows for the provisioning and de-provisioning of user accounts to or from any connected resource.  It also grants employees a central place to go to request access to these resources, allowing for designated individuals to approve or deny the request before access is granted.  The issues of granting a new user access to all of their necessary resources, and removing a user’s access from resources when they leave the organization, can all be solved by a click of the mouse through the central platform of Identity Management.

I hope you all have found this article helpful.  If you have any questions regarding Identity Management, feel free to leave your comments here. I’ll be happy to answer any questions you may have.

 

Action Identity is a premier provider of Identity and Access Management solutions, offering solutions from distinguished partners like Oracle, Novell, NetIQ, ForgeRock, and Symplified to name a few. To learn more about Identity Management and a tailored solution for your company, please visit Action Identity’s website. To contact us directly, please click here. 

 

 

Simiar Articles: 
What is IDM? 
Google Apps for Business & the Cloud
Much to do about Gmail, Password Management, and Your Smartphone
Read more...

Google Apps for Business & the Cloud

 

Everyone working directly or indirectly with IT has heard the word "cloud" uttered numerous times over the last two years. The term can be defined in many ways depending on who you are talking to and what the context of the conversation is. One very simple definition relates to the idea of accessing a service that is not running on systems within an organization's data center(s). One such example is the idea of running traditional desktop software applications via the web browser. These applications could include: email, calendar, contacts, word processing, spreadsheets, slide presentations, and collaborative work on documents. Over the last 15-20 years, Microsoft has had the vast majority of the market share with its Office and Exchange products. This required the Office software to be installed on each individual PC and having the Outlook application point to an Exchange server running within the organization's data center(s). With the steady increase in services being offered in the "cloud," other options are now available to customers. In February of 2007 Google introduced their version of running these applications in the cloud. During the last five years, over four million businesses have decided to implement "Google Apps for Business" as their methodology for running some or all of these applications. When customers approach the end of their enterprise license agreement with Microsoft for Office and Exchange, they may consider moving to Google Apps for Business as an alternative. There are circumstances where Google Apps is potentially a perfect fit and there are circumstances where it may not be a viable option. Consider the following:

Potential Benefits for Migrating to Google Apps for Business:

* Email, Calendar, Contacts, Word Processing, Spreadsheets, Slide Presentations, Document Collaboration are all available in the web browser
* No ongoing maintenance of desktop software
* No servers necessary to maintain in the data center
* Enhancements are continually migrated into the product over time
* 99.9% "up time" Service Level Agreement (SLA)
* Complies with an SSAE 16 Type II audit
* Has achieved FISMA (Federal Information Security Management Act) certification
* 2 Step Verification available at no extra cost
* Employees need to use a wide range of mobile devices including Android, iPhone, Windows Mobile, and Blackberries for email as well as other applications.
* Simple and predictable licensing model

Potential Reasons for not Migrating to Google Apps for Business:

* Spreadsheet "power users" will not have access to all the functionality they may be used to
* Outlook users who are used to certain features when connected to Exchange will either have to switch over to the web interface or be willing to go without certain features
* Technical support is limited via email and phone
* Certain organizations may require more than the 99.9% up time SLA.

 

Google Apps for Business is not a perfect fit for all organizations.  It is a great option for some and not for others. What about your organization?  Would it work for you?  Why or why not?

 

To learn more about Action Identity and the services we provide, visit our website. To contact us directly, please click here. 

 

Similar Reading: 
Much to do about Gmail, Password Management, and Your Smartphone
Benefits of a Web Service
Web Service Protocols 
Read more…

We're on YouTube!

We're on YouTube! Check out our collection of videos on the CJIS Mandate and HID Global's NaviGO product line!

 

To learn more about Action Identity, visit our website

To view our YouTube channel, follow this link

 

For More information on the CJIS Mandate,

Becoming Compliant with the CJIS Security Policy
CJIS Advanced Authentication Requirements and Microsoft Active Directory
The Benefits of Using HID to Secure your Company

Identity Management Lessons from Sarah Palin

By now many of you have already heard about the hacking of Alaska Governor Sarah Palin's Yahoo email account earlier this week (on or about Tuesday 9/16/2008). If not, here is a brief synopsys of the story.

Sarah Palin's personal Yahoo email account was compromised and the contents of her account (including her address book, inbox, and several family photos) were posted to the Internet.

Someone with the email address of rubico10@yahoo.com posted a message on the website 4chan about how he used Yahoo! Mail's password-recovery tool to change the Alaska governor's password and gain full access to her email account.

"i am the lurker who did it, and i would like to tell the story," rubico10@yahoo.com wrote.

(I have included the full text at the bottom of the post for those interested. Be forewarned that some of the language is NOT family friendly.)

The rubico10@yahoo.com email account has been linked to 20-year old David Kernell; son of democratic Tennessee state representative Mike Kernell and a student at the University of Tennessee-Knoxville. While David has not been included in any official investigation as of yet, his father, has confirmed that the person being the subject of the many blog posts and news articles around the Internet is indeed his son.

So how did the alleged hacker do it?

First of all, he had to identify Sarah Palin's email address to be gov.palin@yahoo.com. A recent article in the Washington Post indicated that Sarah Palin was using a personal email address of gov.sarah@yahoo.com to conduct government business. But that was not the email account that got hacked. So how do you get from gov.sarah@yahoo.com to gov.palin@yahoo.com?

Allahpundit posted an article on hotair.com that presents some interesting ideas about how the hacker might have arrived at the gov.palin@yahoo.com account, but for the time being (and void of any conspiracy theories) let's just assume he figured it out.

Now that he had the email address, how was he able to gain access to the account?

The hacker claims to have used Yahoo! Mail''s password-recovery tool to reset the password. To do this, you simply go to Yahoo! Mail and click on the Forget your ID or password link.

This takes you to a page where you enter your Yahoo! ID. In the case of Sarah Palin's account, this would be "gov.palin".





To reset your password with Yahoo! Mail, you can either have it sent to your secondary email address or you can indicate that you no longer have access to this account.

(As a side note, I do not particularly like the fact that Yahoo! shows even a portion of my secondary email account in the email address HINT. But that is another story. )

Selecting the "I can't access my alternate email address" radio button allows you to answer questions to challenge questions as follows:





These are generic authentication questions, but in the case of Sarah Palin, the hacker had to answer one additional question that had to do with where she met her husband. The hacker guessed that Alaska's governor had met her husband in high school, and knew the Republican vice presidential candidate's date of birth and home Zip code, the Associated Press reported. Using those details, the hacker was able to successfully access Palin's email account where he was able to assign a new password of "popcorn".

The rest is simply news.

So what does the hacking of Sarah Palin's email account tell us about security and identity management in general?

One of the big benefits of an identity management solution is that it provides end-users with a way to update their own data and reset their own passwords. This is a HUGE cost reduction for companies as it reduces the number of calls to the Help Desk. But just like everything else, there has to be a careful balance between security and convenience.

Authentication questions provide a means for users to gain access to their accounts when they have forgotten their passwords. This is the mechanism that Yahoo! Mail uses and has been adopted by many identity management solutions. Authentication questions are extremely convenient for companies that have password policies that are so stringent that their users cannot remember their passwords. They also come in handy after three-day holiday weekends as the day that employees return to work typically generates numerous calls to the Help Desk for password reset.

While authentication questions are convenient and produce a cost savings, a company does, however, need to take care when providing this solution. Who decides what the questions are and what happens if the end-user does not have an answer for a particular question? These are some of the issues that need to be considered. I have seen questions all over the board. Below are some of the ones that I find particularly insecure since many of them can be answered by Google searches or social engineering. In some cases, the questions cannot be answered with one answer and some cannot be answered at all.

Questions that can be answered by social engineering or search:

• What is your mother's maiden name?
• In what city where you born?
• In what year where you born?
• What was your first school?
• What was your first phone number?

Questions that might not be answered at all:

• Who is your favorite superhero?
• What is your pet's name?
• What is your library card number?
• What was your first teacher's name?
• What is the air speed velocity of a coconut-laden swallow?

If you force a user to provide answers that are easily obtainable, then your risk is drastically increased (just ask Sarah Palin). If you force users to answer questions that are difficult (or impossible) to answer, then then your risk is also increased as the user may just provide a common answer to all questions (i.e. "blue"). So either way you go, it can be a difficult decision to make.

I have found that one of the best mechanisms is a an approach that allows the end user to define their own set of authentication questions while the company provides a sample set of common (yet hopefully secure) questions as well. This allows the company to have certain control, but also allows the user the ability to provide questions and answers using information that only they know. Now, I know that some may argue that users typically pick the path of least resistance and that many of them will pick easy questions (and therefore have easy answers) but by combining a set of the company-specific questions in addition to those supplied by the user the company can bridge the gap between security and convenience.

By the way, if you use an application that allows you to provide your own authentication questions, then I STRONGLY suggest that you go and provide your own security question(s) to one(s) that have meaning and applicability to you.

Here is the synopsis of what rubico said at 4chan:

rubico 09/17/08(Wed)12:57:22 No.85782652 Hello, /b/ as many of you might already know, last night sarah palin’s yahoo was “hacked” and caps were posted on /b/, i am the lurker who did it, and i would like to tell the story. In the past couple days news had come to light about palin using a yahoo mail account, it was in news stories and such, a thread was started full of newfags trying to do something that would not get this off the ground, for the next 2 hours the acct was locked from password recovery presumably from all this bulls**t spamming. after the password recovery was reenabled, it took seriously 45 mins on wikipedia and google to find the info, Birthday? 15 seconds on wikipedia, zip code? well she had always been from wasilla, and it only has 2 zip codes (thanks online postal service!) the second was somewhat harder, the question was “where did you meet your spouse?” did some research, and apparently she had eloped with mister palin after college, if youll look on some of the screensh**s that I took and other fellow anon have so graciously put on photobucket you will see the google search for “palin eloped” or some such in one of the tabs. I found out later though more research that they met at high school, so I did variations of that, high, high school, eventually hit on “Wasilla high” I promptly changed the password to popcorn and took a cold shower… >> rubico 09/17/08(Wed)12:58:04 No.85782727 this is all verifiable if some anal /b/tard wants to think Im a troll, and there isn’t any hard proof to the contrary, but anyone who had followed the thread from the beginning to the 404 will know I probably am not, the picture I posted this topic with is the same one as the original thread. I read though the emails… ALL OF THEM… before I posted, and what I concluded was anticlimactic, there was nothing there, nothing incriminating, nothing that would derail her campaign as I had hoped, all I saw was personal stuff, some clerical stuff from when she was governor…. And pictures of her family I then started a topic on /b/, peeps asked for pics or gtfo and I obliged, then it started to get big Earlier it was just some prank to me, I really wanted to get something incriminating which I was sure there would be, just like all of you anon out there that you think there was some missed opportunity of glory, well there WAS NOTHING, I read everything, every little blackberry confirmation… all the pictures, and there was nothing, and it finally set in, THIS internet was serious business, yes I was behind a proxy, only one, if this s**t ever got to the FBI I was f****d, I panicked, i still wanted the stuff out there but I didn’t know how to rapids**t all that stuff, so I posted the pass on /b/, and then promptly deleted everything, and unplugged my internet and just sat there in a comatose state Then the white knight f****r came along, and did it in for everyone, I trusted /b/ with that email password, I had gotten done what I could do well, then passed the torch , all to be let down by the douchebaggery, good job /b/, this is why we cant have nice things

Submitted By: Bill Nelson (bill.nelson@gca.net)

Directory Servers vs Relational Databases

An interesting question was posed on LinkedIn that asked, "If you were the architect of LinkedIn, MySpace, Facebook or other social networking sites and wanted to model the relationships amongst users and had to use LDAP, what would the schema look like?"

You can find the original post and responses at http://www.linkedin.com/answers/technology/software-development/TCH_SFT/296425-23753864

After reading the responses from other LinkedIn members, I felt compelled to add my proverbial $.02.

---------------------

Directory Servers are simply special purpose data repositories. They are great for some applications and not so great for others. You can extend the schema and create a tree structure to model just about any kind of data for any type of application. But just because you "can" do something does not mean that you "should" do it.

The question becomes should you used a directory server or should you use a relational database. For some applications a directory server would be a definite WRONG choice, for others it is clearly the RIGHT one, for yet others, the choice is not so clear. So how do you decide?

Here are some simply rules of thumb that I have found work for me:

1) How often does your data change?

Keep in mind that directory servers are optimized for reads - this oftentimes comes at the expense of write operations. The reason is that directory servers typically implement extensive indexes that are tied to schema attributes (which by the way are tied to the application fields). So the question becomes, how often do these attributes change? If they do so often, then a directory server may not be the best choice (as you would be constantly rebuilding the indexes). If, however, they are relatively static, then a directory server would be a great choice.

2) What type of data are you trying to model?

If your data can be described in an attribute:value pair (i.e., name:Bill Nelson), then a directory server would be a good choice. If, however, your data is not so discrete, then a directory server should not be used. For instance, uploads to YouTube should NOT be kept in a directory server. User profiles in LinkedIn, however, would be.

3) Can your data be modeled in a hierarchical (tree-like) structure?

Directory servers implement a hierarchical structure for data modeling (similar to a file system layout). A benefit of a directory server is the ability to apply access control at a particular point in the tree and have that apply to all child elements in the tree structure. Additionally, you can start searching at a lower (child element) and increase your search performance times (much like selecting the proper starting point for the Unix "find" command). Relational databases cannot do this - you have to search all entries in the table. If your data lends to a hierarchical structure then a directory server might be a good choice.

I am a big fan on directory servers and have architected/implemented projects that sit 100% on top of a directory, 100% on top of relational databases, and a hybrid of both. Directory servers are extremely fast, flexible, scalable, and are able to handle the type of traffic you see on the Internet very well. Their ability to implement chaining, referrals, web services, and a flexible data modeling structure make them a very nice choice to use as a data repository to many applications, but I would not always lead with a directory server for every application.
So how do you decide which is best? It all comes down to the application, itself, and the way you want to access your data.

A site like LinkedIn might actually be modeled pretty well with a directory server as quite a bit of the content is actually static, lends well to an attribute:value pair, and can easily be modeled in a heirarchical structure. The user profiles for a site like facebook or YouTube could easily be modeled in a directory server, but I would NOT attempt to reference the YouTube or facebook uploads or the "what are you working on now" status with a directory server as it is constantly changing.

If you do decide to use a directory server, here are the general steps you should consider for development (your mileage may vary, but probably not too much).

1. Evaluate the data fields that you want to access from your application
2. Map the fields to existing directory server schema (extend if necessary)
3. Build a heirarchical structure to model your data as appropriate (this is called the directory information tree, or DIT)
4. Architect a directory solution based on where your applications reside thorughout the world (do you need one, two, or multiple directories?) and then determine how you want your data to flow through the system (chaining, referrals, replication)
5. Implement the appropriate access control for attributes or the DIT in general
6. Implement an effective indexing strategy to increase performance
7. Test, test, test

Submitted By: Bill Nelson (bill.nelson@gca.net)

Lessons Learned from Enterprise Identity Management Projects

I have been implementing and/or managing identity-related projects for over ten years now and I can say from experience that the biggest problem with any identity management project can be summed up in one word - EXPECTATIONS.

It does not matter whether you are tackling an identity project for compliance, security, or cost-reduction reasons you need to have proper expectations of what can be realistically accomplished within a reasonable timeframe and those expectations need to be shared among all team members and stakeholders.

Projects that fail to achieve a customer's expectations do so because those expectations were either not validated or were not shared between all parties involved. When expectations are set (typically in a statement of work), communicated (periodic reports), and then reset if necessary (change orders), then the customer is much happier with the project results.

Here are a few lessons I have learned over the years. While they have general applicability to major projects, in general, they are especially true of identity-related projects.

1) Projects MUST be implemented in bite-sized chunks.

Identity projects are enterprise-wide projects; you should create an project roadmap that consists of multiple "mini" projects that can demonstrate an immediate ROI. The joke is, "How do you eat an elephant? One bite at a time." To achieve success with identity projects, you should implement them one bite at a time and have demonstrable/measurable success after each bite.

2) The devil is in the data.

Using development/test data that is not representative of production data will kill you in the end and cause undue rework when going into production. Use data that is as close to production as possible.

3) Start with an analysis phase BEFORE scoping the entire project.

I HIGHLY recommend that the first project you undertake is an analysis. That will define the scope for which you can then get a better idea of how to divvy up the project into multiple bite size chunks and then determine how much (and how long) each chunk will take. This allows you to effectively budget both time and money for the project(s).

Note: If a vendor gives you a price for an identity implementation without this, then run the other way. They are trying to simply get their foot in the door without first understanding your environment. If they say that the analysis phase is part of the project pricing, then get ready for an extensive barrage of change orders to the project.

4) Get everyone involved.

Keep in mind that these are enterprise-wide projects that affect multiple business units within your company. The project team should contain representatives from each organization that is being "touched" by the solution. This includes HR, IT, Help Desk, Training, and above all, upper-level management (C-level).

(The following items apply if you are using external resources for project implementation.)

5) Find someone who has "been there and done that".

Ask for references and follow up on them. More and more companies say that they can implement identity-related projects just because they have taken the latest course from the vendor. This is not enough; if training alone could give you the skills to implement the product, then you would have done the project yourself. You need to find someone who knows where the pitfalls are before you hit them.

6) Let the experts lead.

Don't try to manage an identity management project unless you have done so before - more than once. I have been involved with customers who have great project managers that have no experience with identity projects - yet they want to take ownership of the project and manage the resources. This is a recipe for disaster. Let the people who have done the implementation lead the project and allow your project manager to gain the knowledge for future phases.

7) Help build the car, don't just take the keys.

Training takes place before, after, and during the project. Don't expect to simply take "the keys" from the vendor once the project has been completed. You need to have resources actively involved throughout the project in order to take ownership. Otherwise you not be able to support the product (or make changes to it) without assistance from the vendor. Ensure that you have your own team members actively engaged in the project - side by side with the external team. To do this, you have to ensure that they are not distracted by other work-related tasks.

Submitted By: Bill Nelson