Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

@Username

Hello all,

Is there a way, at/after login, to populate @Username with a different value, say, the person's LAN ID?

I know that in the login process, the @Username goes from SYSPROG to the App ID to the actual User ID. Just wondered if there was a way to bypass at least the last part and stuff something else in its place.

Thanks in advance!

Michael

Comments

  • And/or is there a way to leverage the SSO logic to achieve this end?
  • Unfortunately, no. This is all handled very early in the initialization process and that variable is read-only.
  • Out of curiosity, why not just set up SSO? That way you could get the LAN ID in @USERNAME. FWIW, this is why we don't rely on @USERNAME. We prefer to roll out our own username management and use UDPs instead.
  • I totally agree, but my client has a zillion references to @Username that we don't want to have to modify.

    SSO is definitely the way to go. Can I configure SSO to apply to one application, or is it per install/license?
  • Nevermind.. I got it.. Play time..lol
  • Very good. However, since you asked the question and others might be curious...yes, you can configure SSO in OI to specific applications. We consider that to be the best practice because you will always want a way to log into OI without SSO as a back door.
  • Ok, I've set up a SYSENV record for SSO. Field 1 is 2, field 4 is a group name. The ID is CFG_LOGIN*applicationname. There is no password on the application.

    When I log in from the command line, I pass a /AP=applicationname. It's still prompting for username and password (with the applicationname in the username prompt).

    What might I be doing wrong?
  • Did your network admins create an LDAP group of the same name as in field 4 and is LAN ID a member of this group?
  • Yes and Yes, sir
  • If you attempt to login using the normal OI username and password, does it let you in? Also, what is the value in field 5?
  • Yes it does. And there's nothing in field 5. Should there be?
  • Field 5 can be empty. It just means you want the default (i.e., Only LDAP groups are checked for membership).

    If you are able to login normally, this implies that SSO is not enabled. OI errors out when you attempt to login normally and when SSO is enabled.

    I am relatively certain that the LDAP group names are case sensitive, so make sure that is not an issue. I'm also wondering if the absence of LDAP group names in fields 2 and 3 is a problem. To test this theory, put the same LDAP group in those fields.
  • Field 5 is empty. I did notice the CFG_Login record for the application (with 0 in field 1) also has 0 in field 5. Does that matter?

    I put the same LDAP group name in fields 2-4. Same result.
  • 0 in field 5 is the default. So an empty field is the same as 0. At least that's what the documentation says. You can always test this and put a 0 there to confirm.

    Something is definitely wrong but I can't identify what the issue is. I just did a quick test on my local machine and I'm getting SSO enforced (i.e., because I don't have LDAP or AD enabled, OI is giving me a boot failure).

    I'm inclined to think something is off with the CFG_LOGIN record or its Key ID in the SYSENV table, but this is pretty basic stuff so I highly doubt you have a problem here.

    Are you sure that your workstation is able to communicate with the LDAP server? I've had issues where the LDAP server wasn't visible to the workstations so SSO wasn't working.
Sign In or Register to comment.