cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1580
Views
0
Helpful
5
Replies

COBRAS warning message and PIN problem CUC 7.0 ->9.1

ealeatherman
Level 4
Level 4

Hello!

This weekend I exported some voice mail accounts from Connection 7.0.2 and imported them into 9.1(2) using COBRAS tool.

When I did this, the users were not able to sign into their mailbox, PINs didnt work.

Retracing my steps, I did have this showing up in the COBRAS log during the import for each mailbox:

[Thread 001], [14/03/02 08:51:34],         Updating subscriber phone PIN from Connection backup

[Thread 001], [14/03/02 08:51:34], (warning) unable to find mapping for MDBObjectId=051ee60c-4e21-42f6-bea4-9f845e6e96c8, ObjectType=CredentialPolicy in GetNewObjectId on DirectoryBackupDatabaseFunctions.cs

Unfortunately I had did not have a whole lot of time to troubleshoot on live 9.1 server - weather emergency dictated that I swing them back the 7.0 version asap so that users could update various greetings and info prompts. Right now i'm working with the 9.1 VM in a isolated network - unfortunately I don't have a CUCM in that network to test calls into it.

My hypothesis is that the old system had PIN set to not expire, and the new system has PIN set to expire in 120 days - and this somehow caused the PIN to not get updated somehow. I can't see any other difference related to credential policy. Tomorrow I'm going to try and re-import a user from cobras backup with the PINs on the system set to not expire now, and see if it makes a difference in the import log. Anyone know if this is the case or why PINs might not have carried over, or if I'm barking up the wrong tree?

I had read that there was some issues importing PINs into version 7.0, but exporting from 7.0 TO a version 7.1.3+ was not cited as a problem - unless I am misunderstanding (totally possible!).

Thanks!

1 Accepted Solution

Accepted Solutions

The hash logic for Unity, Windows Connection and then Linux Connection servers have all changed over time (more than once in the case of Linux based Connection).  Since the PIN and PW hashes cannot be “unhashed” they can only be validated there’s no (easy) way for clients to somehow retrieve the original password and then create a new updated hash on the fly - the hash is simply ported as is and a note made about the hash style for the version of Unity/Connection it's coming from.

So if sites never force users to change their passwords and PINs (really not a good idea… they should be changed at least a couple times a year at any rate) and they’ve ported those users from older hash techniques into newer servers, the “first hop” will work fine.  So if you’re coming from Unity 4.x to Connection 7.x it will work without issue.  If, however, those users sit with the same PINs indefinitely and you move them _again_ to say Connection 10.x they will not work.  All COBRAS knows is the version of Connection they are coming from and must _assume_ the PIN/PW hash matches that version – in this case since they’ve never been forced to change their PINs/PWs their hashes are actually not in the Connection 7.x style but in the older Unity style.  Not good.  COBRAS cannot “Fix” this on the fly even falling back on deeply hacky "hash checks" to try and guess the original version of the application they were created in (these are sloppy, evil and not reliable).

Short version – sites should use quality security policies and not let their users park on the same PINs and Passwords for years on end. 

If you’re not sure forcing everyone to change their PIN prior to a migration is not a bad move. 

View solution in original post

5 Replies 5

ealeatherman
Level 4
Level 4

After some conversations with some users, it turns out that only some users could not log in - and they were users that had been on the system a long time and had never changed their PINs. This seems to point to the password hash issue with importing older accounts. When I was reading the cobras documentation I misunderstood the issue and thought that importing to later versions of unity connection would work OK - probably time to re-think my upgrade plan.

The hash logic for Unity, Windows Connection and then Linux Connection servers have all changed over time (more than once in the case of Linux based Connection).  Since the PIN and PW hashes cannot be “unhashed” they can only be validated there’s no (easy) way for clients to somehow retrieve the original password and then create a new updated hash on the fly - the hash is simply ported as is and a note made about the hash style for the version of Unity/Connection it's coming from.

So if sites never force users to change their passwords and PINs (really not a good idea… they should be changed at least a couple times a year at any rate) and they’ve ported those users from older hash techniques into newer servers, the “first hop” will work fine.  So if you’re coming from Unity 4.x to Connection 7.x it will work without issue.  If, however, those users sit with the same PINs indefinitely and you move them _again_ to say Connection 10.x they will not work.  All COBRAS knows is the version of Connection they are coming from and must _assume_ the PIN/PW hash matches that version – in this case since they’ve never been forced to change their PINs/PWs their hashes are actually not in the Connection 7.x style but in the older Unity style.  Not good.  COBRAS cannot “Fix” this on the fly even falling back on deeply hacky "hash checks" to try and guess the original version of the application they were created in (these are sloppy, evil and not reliable).

Short version – sites should use quality security policies and not let their users park on the same PINs and Passwords for years on end. 

If you’re not sure forcing everyone to change their PIN prior to a migration is not a bad move. 

Thanks for the explanation Jeff!

I agree about enforcing PIN changes, unfortunately isn't my call. I just suggested similar moving forward and was told basically "over their dead bodies."

Thanks for this Jeff. I have a follow up question.

We ran into a problem when we migrated from Unity v4.0 to Connection v7.1(2). Because I didn't use the latest COBRAS tool, the password hash was not correct and we had to force people to change their password after we did a bulk reset of passwords. As a result, the majority of users have changed their password on v7.1(2).

We have since upgrade to v7.1(3)ES11 and are planning on upgrading to v9.1(2)SU1 [or whatever is available]. We will not be using COBRAS, but doing a direct upgrade (albeit offline).

Considering that we will _not_ be using COBRAS and that the majority of users have changed their password while we were on v7.1(2), are we going to be OK?

Lelio

I have a somewhat related question, does COBRAS preserve PINs for user templates?  I've migrated user templates from CUC 10.5 to 11.5 and noticed couple of things did not carry over, the default PINs and mailbox quotas set at the template level.  Interestingly message quotas do carry over at user level, just not template, is this expected?