I just went in to test this using a text-transform CSS tag and it doesn't seem to work right. While I can make the text appear lowercase in the form, if I type uppercase when I enter the login name it displays it in lowercase but passes the uppercase value to the Remedy system.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Doug Blair Sent: Wednesday, November 07, 2007 3:19 PM To: [email protected] Subject: Re: Case Sensitive User IDs? It's a little more subtle than that. If your user enters a login name and it's passed out to AREA/LDAP for authentication and the LDAP source is case-insensitive (for example Active Directory) then the user will be authenticated regardless of case. The username returned from AREA will be the username stored in the LDAP source, which might not match (case-wise) the user name typed by the user! So you enter: joeuser (all lower) and your AD SAMAccountName contains JoeUsER (mixed case) you will be an authenticated user named JoeUsER (mixed case). There is no such user in ARS' User form so you are authenticated, with nothing but a read/guest license and no groups. The only solutions for this is to write your own plugin or wrapper around the LDAP process that will force the user name to your perferred convention (e.g. lowercase) even if AD returns something different, or return the original text entered by the user, or to cleanup the contents of the account name (sic) field in your active directory. And make sure everybody enters the data that way going forward. None of these sound like fun! The combination of forcing the user to type all lowercase on the web login page with a text-decoration and making all the AD entries lowercase DOES work, but is not pretty :-) Doug ___ Doug Blair Remedy Skilled Professional doug<at>blairing<dot>com +1-224-558-5462 ...... Original Message ....... On Wed, 7 Nov 2007 10:18:10 -0800 Thad K Esser <[EMAIL PROTECTED]> wrote: >** >I've never pursued it fully, but it seems that while your DB may be case insensitive, Remedy itself is case sensitive. I had an issue once where I was using the 'Assigned To' field in workflow, but it was causing problems because the database name of the field was actually 'Assigned to'. That was fun to figure out. > >Anyway, it sounds like the login process has the same case issues. There was a thread not too long ago about how to modify the login.jsp on the Mid-Tier so that it would force the login name to a certain case. Not much help in a mixed environment, I know, but I thought I'd mention it. > >Thad Esser >Remedy Developer >"Argue for your limitations, and sure enough, they're yours."-- Richard Bach > > >"Sokol, Brian" <[EMAIL PROTECTED]> >Sent by: "Action Request System discussion list(ARSList)" <[email protected]> > >11/07/2007 09:50 AM > >Please respond to >[email protected] > > > >To >[email protected] > >cc > > >Subject >Re: Case Sensitive User IDs? > > > > >No guest allowed. What I believe is happening is this. >Account in Remedy User: joeuser >Network Account: JoeUser >Authentication Alias(117): Joeuser > >The user tries to logon as Joeuser. Even though their account is in the >User form as joeuser, Remedy sees them as an unregistered user and logs >them in with a read license. So does the end user have to type their >account exactly as it is (all lower case) in the User form? My database >is case insensitive. I would think it would not matter if they typed >joeuser, Joeuser or joeuSer. > >-----Original Message----- >From: Action Request System discussion list(ARSList) >[mailto:[EMAIL PROTECTED] On Behalf Of Joseph Kubasek >Sent: Wednesday, November 07, 2007 12:28 PM >To: [email protected] >Subject: Re: Case Sensitive User IDs? > >Do you allow guests? Is it possible the the users are getting logged in >as a guest. For example: >Network account: JoeUser >remedy account: joeuser >User types: JoeUser > >In this case, if you allow unauthenticated guests, then remedy would log >the user in as the guest user JoeUser instead of the the defined user >joeuser. > >Joe Kubasek > >On Nov 7, 2007 9:46 AM, Sokol, Brian <[EMAIL PROTECTED]> wrote: >> ** >> >> >> Can someone clear this up for me as it seems to come up a couple times > >> per year. We are using network authentication (not area ldap). Both >> cross reference blank passwords and authenticate unregistered users >are checked. >> All our staff have blank passwords in the User form. Every now and >> then a user only gets a read license. The problem seems to occur when >> the user enters an ID in Remedy that does not match the case >> sensitivity of their network account (network account is JoeUser, >> Remedy account is joeuser). I am using the special field >> Authentication Login Name (field ID 117) which matches exactly their >network ID. >> >> Any ideas why this happens? Is the Remedy user ID case sensitive? >> Shouldn't field ID 117 fix any problem? Is this another old bug >> reintroduced by my upgrade to 7.1? >> >> One other question. In the user log I am seeing Impersonated by >> MidTier Service when some users login? >> >> ARS/MidTier 7.1 on IIS. >> >> Thanks >> >> Brian Sokol >> Manager, Desktop Services >> Scholastic Inc. >> 557 Broadway >> NY, NY 10012 >> (212) 343-6494 >> http://www.Scholastic.com __20060125_______________________This >> posting was submitted with HTML in it___ > >_______________________________________________________________________ _ >_______ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum >Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > >_______________________________________________________________________ ________ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > > > >***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.*** > >__20060125_______________________This posting was submitted with HTML in it___ ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" Private and confidential as detailed <a href="http://www.sug.com/disclaimers/default.htm#Mail";>here</a>. If you cannot access hyperlink, please e-mail sender. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
