| Author |
Message |
![[Post New]](/Sysforums/templates/default/images/icon_minipost_new.gif) 18/04/2012 17:00:46
|
Cygnus16
SysAider
Joined: 17/02/2012
Messages: 14
Offline
|
After upgrading to 8.5.04 initially, the "cascading" feature of LDAP integration went away, so I had added all of the specific OUs and Sub-OUs that I wanted to import into Sysaid. This worked very well. For some reason after updating to the latest (yet "unreleased") patch, not all of my users are being enabled properly. I found that there was a checkbox to enable Searching Sub-OUs, and I turned that off.
All of the appropriate users will be imported, but a huge slew of people were being left out. I've cross checked a few enabled accounts with a few disabled accounts, and I can't see any glaring difference (using ADQuery). My current settings are as follows, and remember, they worked perfectly well before updating:
User Class Filter: (&(objectclass=user)(!(userAccountControl=66050))) <----This will stop the import of anyone with a 66050 UAC flag, which in my domain means the account is disabled, ie a normal user has 66048
User Filter: (sAMAccountName={0}) <---- Can somebody explain what the significance of the {0} is? I'm newly familiar with AD queries and cannot figure out exactly what this statement is saying.
Name Attribute: sAMAccountName
With these settings, before, it would import all of the enabled users in my domain, and automatically enable within Sysaid, everyone that it imported. If a user was disabled in AD, then during the next scheduled import, they would be disabled within Sysaid accordingly. Okay, now is where this gets messy.
I've kind of figured out why these users will not be enabled, and from what I can tell it has to do with the format in which they are being imported. If I delete every user, and reimport, it pulls everyone down from AD and enables them properly, BUT the User ID attribute becomes Domain\Username. It used to be just Username, which means the entry for "User ID" and "Username" within Sysaid matched exactly. I'm not upset about that, but what it does is detach all associations with past and current service requests! I have a test server to mess around with so I will try any and all suggestions.
Is there any way to pull ONLY the USERNAME portion without the "DOMAIN\" from AD? Any thoughts that it might have something to do with the Network User option going away from Preferences>End User Portal>User's Asset Determined by? Mine now says Domain and User. Used to say Network User.
|
|
|
19/04/2012 14:48:37
|
CarlH
Elite SysAider
Joined: 30/01/2009
Messages: 178
Offline
|
I'm with you here. When I asked them if they could change domain\username to just "Firstname Lastname" like it used to be and that was shot down
|
|
|
19/04/2012 15:21:00
|
Cygnus16
SysAider
Joined: 17/02/2012
Messages: 14
Offline
|
I guess what I don't understand, is why the User ID (taken from LDAP) is the associating key with the Service Request, and not the Sysaid "Username". The Sysaid Username in my case has not changed. It manages to remove the "Domain\" part, and only use the bare username. If it were possible to connect the user to the SR using the Sysaid Username, then this would be a non issue. I really could care less what information is pulled from LDAP, just as long as I don't lose that association.
Also, in response to your post, I'm not so sure it was ever "Firstname Lastname." Granted, I've only used Sysaid since version 5.0. I know that within the list view, the users show up as Firstname Lastname, but if they don't have anything in those fields, then their "User ID" (Domain\User) shows up in the "Request User" field.
|
|
|
20/04/2012 15:35:11
|
amb1
SysAider
Joined: 08/12/2011
Messages: 2
Offline
|
I had the same issue and was told they completely changed the way LDAP was loaded by "User Request". Have fun if you have any sub OU's - they have to be listed out individually...
I say we all cancel yearly maintenance - if this is how "Upgrades" are handled I'm not interested in them!
|
|
|
20/04/2012 19:12:14
|
Cygnus16
SysAider
Joined: 17/02/2012
Messages: 14
Offline
|
Soooo, I ended up fixing it. Well, not so much fixed, but rather I modified all of my service requests to update the "request user" field from "username" to "domain\username." I use SQL Server 2008 for my database, so I'm not sure how to do it with Derby or another DBMS, but it's probably similar.
These are the steps I took:
I did a search to get all of the unique request users:
Then I deleted all of the admin's names (I don't import the admins from LDAP to avoid catastrophe) so that they aren't affected. I also deleted any newer users who had been imported in the new format from the get go. I saved that output to a CSV file.
Then I wrote a little java program because I'm not a programmer and java is the only thing I've ever used. I'll attach the source to this post if anyone wants to tweak it for themselves (the class is called replace.java). It basically reads the CSV file, and outputs the following SQL statement for each name it finds in the file:
I didn't output it to a file, I just copied what was displayed within the console in Eclipse and pasted that into a blank query in SQL Server Management Studio. So you're basically left with a long list of of the above statement, and it will look for each SR where the username is in the "username" format, and replace it with "DOMAIN\username" format.
Also note, it's looking in the "ilient1" database (standard name is "ilient"). This is a test DB that I created, I suggest you do the same to prevent something bad from happening. Good luck, I hope that helps anyone else that runs into this problem. There's probably a better way to do it, but this is what I figure out this morning before lunch.
| Filename |
Sysaid Username Replace.zip |
|
| Description |
Source for the java thing I "wrote" |
| Filesize |
4 Kbytes
|
| Downloaded: |
7 time(s) |
This message was edited 2 times. Last update was at 20/04/2012 20:21:56
|
|
|
12/05/2012 08:22:46
|
assker
SysAider
Joined: 22/04/2010
Messages: 6
Offline
|
I am also experiencing this issue.
|
|
|
14/05/2012 15:24:04
|
Cygnus16
SysAider
Joined: 17/02/2012
Messages: 14
Offline
|
You will basically need to remove all of your users, then re-import them like I did. It's the only way I've found will work. Then, of course, you'll have to reassign the request user on all of the service requests in your system, otherwise your users will lose their entire request history, including current/active requests.
You could look at that code I attached in my post above, and attempt it that way. If you are worried about hosing your entire database, I would suggest setting up a test server and Database to double check that everything will work correctly.
|
|
|
![[Up]](/Sysforums/templates/default/images/icon_up.gif){kind=icon}
