One of our Spice Admins has created a ticket. At this organisation we have (at least) two email addresses. His spice login is stevea@dom.org.nz and his email address is steve.allen@dom.org.nz. The ticket has steve.allen against it so that when he clicks on the ticket link in his email the portal opens but an "Unauthorised" message appears.

This is not an isolated case as another user who has a ticket first.last@dom cannot login and check all the tickets as some are also addirname@dom.

13 Replies

Spiceworks did quite a bit of work to get persistence for Admin logins to Spiceworks and from your description it is probable that this persistence is problematic.

For example, if Steve logs into Spiceworks using his Spiceworks login, does a bit of work, then clicks on the email notification link the identity of the ticket owner is not the same as the Admin user logged in to Spiceworks.

This is very easy to test. Have Steve attempt the same link to the portal from a PC or VM he has not used as a SW Admin and if it works, which I suspect it will, there is the problem highlighted.

We run a 3 level Helpdesk and 5 instances of Spiceworks in-house and many more than that on client sites. We had a number of issues with users and admins with multiple email identities and had to come up with procedures and methods to account for persistent logon to Spiceworks. This is not the same, but just as problematic as trying to use the community from multiple Spiceworks instances with the same Spiceworks ID.

To resolve this issue, if the theory above is proven, then it is probably easiest to have the users be careful to only submit tickets and for Admins only logon to Spiceworks and submit tickets with one of their email accounts.

Then persistence will work in your favour, rather than work against you as it is now.

The ideal solution may however differ depending how the differing email identities are used in your business. If you are able to confirm persistence is causing the problem, some additional local needs consideration may be required.

I am positive that this is the problem. When interrogating the database directly (SQLite Browser) I can see that there are many cases in the USERS table where there are two email addresses and, of course, this creates a unique ID/record in that table. Also, even if the email address entered MANUALLY into a ticket is incorrect and the subsequent email fails to get delivered, the incorrect address generates a user id/record in the user table. So, short of manually adjusting every ticket for consistency, I am after a method to get our DBA to script a query that can fix this.

But...I tried to adjust the initial user to have just one email address and nothing has changed. Therefore the problem is not just restricted to the USER table but has repercussions in other areas. So any query/manual adjustment of the USER table will have to be able to alter every instance of the dual-address syndrome across every affected table.

In the 'tickets' table of the db, the 'created_by' field records the owner of the ticket, so depending how up to it your DBA is, what needs to happen is any tickets owend by the superfluous user ID, needs to have this 'created_by' field changed to represent the preferred user ID.

Of course there needs to be backup taken before any database modifications are made just in case. Then test the theoretic change of ticket owner on one user, say Steve and then your DBA should have what he needs to script all the changes, then remove the redundant users.

This method can also be used in instances where a user has created a ticket with an email address with a typo in it, a bit fiddly but it works.

You can see the problem here? Given that everyone will login to the portal using the first example (even though I have never managed to get LDAP and portal working) but if they submit a request via an email message the ticket gets generated with their default email address.

Spiceworks allows username@domain.org.nz or domain\username (if DNS is working properly the first instance does not require FQDN). When AD authentication is configured, Spiceworks reads the email address from the AD User record.

In the Tickets table the owner of the ticket id identified by their ID from the User table.

In the User table you will find that Users are identified by their email address, not name or domain login. Only Spiceworks Admins have name detail recorded.

If your AD authentication is working, if someone logs into the portal, using AD credentials, for the first time, they are added to the user table in Spiceworks based on the primary email address defined in the AD for that user. If they email in an email for their first use Spiceworks looks for that email in the AD to associate that user. If a user logs into the portal and there is no associated email address in the AD Spiceworks prompts the user for their email address and if the credentials used in settings for the AD integrated authentication has sufficient rights, Spiceworks will write the email address provided by the user into AD associated to the currently logged in user. Spiceworks ONLY uses email addresses to assert ownership of tickets, not username/password, which is only used to authenticate.

Keep in mind the issues with Spiceworks Admins also differ to those of end users since they are identified in the user table by more detail and have no association to AD.

The bottom line is if two email addresses are used to submit tickets, two owners will be created in Spiceworks User table, as for the abiguety of the Username/Password login to the portal, Spiceworks will use the predominant email address in AD, which will preculde access to the other set of tickets.

If you used the method described earlier to consolitade ticket ownership and did not use the dominant email address from AD I can see a situation where no tickets would be available and a new user in Spiceworks kept being created after being taken away as part of the ownership clean-up.

I think there are several layers that need to be cleared up here AD email association, method of username used to log into portal and then ownership of the tickets. I understand entirely the distiction, where it gets trickey is if the firstnamesurnameinitial@dom.org.nz is listed in AD as an associated email account and is the dominant one sending in a ticket with the other email address will not be accessible in the portal.

Back to the question, what email addresses are associated in AD?

I'm sorry you feel I don't understand you, it is not a case of needing to be made simple, there is nothing simple about it. You are trying to get accross your understanding of the issue and I'm trying to get accross how Spiceworks uses AD and email addresses. Some variation of your methodology may need to change for your two or more email accounts not to prevent users accessing half their tickets. Particularly if one of these email addresses is the same as the credentials they will authenticate to AD, could be confusing.

To further asser the problem, I'll describe my personal situation. I have 4 email addresses (all associated in AD with my USER ID) but to see my tickets in the portal the tickets have to have been raised using the address defined as the 'Default' on the 'Email Addresses' tab in AD Users & Computers for my account Properties.

I have inadvertently added tickets using other email accounts and they are inaccessible when I log into the Portal, unless I change the ownership of the tickets.

I did some further testing and there is an issue that if a Spiceworks Admin creates a ticket through the Spiceworks Helpdesk directly Spiceworks casts ownership of the ticket to the Spiceworks Admin user. Then when/if that Spiceworks Admin user logs into the portal a new user is created, based on the AD authentication, even if the email address is the same, then from the portal the tickets created by the Spiceworks admin user, in Spiceworks, they are not visible in the portal as this is intended as an end user portal and defaults to to user account rather than the Admin account in the Spiceworks User table.

Any ticket created using the email address associated with the Spiceworks Admin user account, ownership of those tickets are also cast to the Admin user (not the end user account with the same email address) and not viewable through the portal when logged in using AD authentication.

In your case both the issue of multiple email accounts and the issue of an Admin user and End user with the same email address associated, may be in play.

Check the User table and see if the Admin user has an end user account with the same email address. This would go in some way to explain the communication dificulty you feel we have had, there may be 2 issues here not one.

BTW: ticket ownership can be changed using Tickets Anywhere commands, rather than backending the database, but this has to be done one by one so is only really suitable for small numbers of ownership changes.

If user portal AD integration was working (it never has worked despite numerous atempts to get it working) the user would login to the portal with their AD login name - which MAY NOT be the same as their default email address - and submit a request the backend DB identifies them by what...email address or AD login?. If they then submit a request by email - which, in most cases, is NOT the same as their AD login (although they also have an email address named as their login) they will NOT be able to view the tickets created via which method, portal or email?

The problem came to light when a user logged onto the portal with their AD login-named email address (login@org) but could not see the tickets created via email as first.last@org.

Mine cannot be an isolated case, surely?

Maybe a SPICE-delivered tool to reconcile all the differences would be useful...or does the AD integration of the portal recognise ALL the posible email addresses associated with a USER? (let's forget the admins for the time being)

Thank you for your responses. I am still hoping someone from Spice will give an answer which is likely to justify our not deing disheartened by this issue. We have users who cannot access their tickets. Short of re-organising our AD/Exchange policies is there a simpler solution?

We have AD login to the User Portal working fine, but the tickets get a Created By that is more like the domain primary name for the user account, not the value from the email field at all. So at the end of the day, all the tickets created from portal users are not associated with their AD account. The email even displays correctly in the user portal, but it is not used for the Created By.

I do not know if I am expecting it to do something that it does not, or if it is a bug / feature yet to be implemented.