Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

ALEREMOTE ID locked by KRNL

Go to solution
Former Member

‎11-08-2007 5:21 AM

0 Kudos

User ID: ALEREMOTE (system) ID is keep on getting locked, and SUIM - Change log shows it is locked by KRNL. Any idea what it means and how do we go about preventing this? Thanks.

1 ACCEPTED SOLUTION

Go to solution
Former Member

‎11-08-2007 4:59 PM

0 Kudos

this would be because of wrong password entry in the RFC connections. multiple attempts might have caused the user lock.

look at the list of RFC's where ALEREMOTE is getting used.the easiest way would be executing the report RSRFCCHK to take a look at the list of RFC's where ALEREMOTE is getting used and do a connection test individually and see which RFC is causing this and then correct the password in the RFC. and also check in the system where that destination is going. because it will be locked on that system too.

and if you have NW 04s system which is causing this error. you be carefull when you determine the password in the RFC because NW04s systems are case-sensitive with passwords.

Message was edited by:

Keerti Vemulapalli

Message was edited by:

Keerti Vemulapalli

2 REPLIES 2

Go to solution
Former Member

‎11-08-2007 4:59 PM

0 Kudos

this would be because of wrong password entry in the RFC connections. multiple attempts might have caused the user lock.

look at the list of RFC's where ALEREMOTE is getting used.the easiest way would be executing the report RSRFCCHK to take a look at the list of RFC's where ALEREMOTE is getting used and do a connection test individually and see which RFC is causing this and then correct the password in the RFC. and also check in the system where that destination is going. because it will be locked on that system too.

and if you have NW 04s system which is causing this error. you be carefull when you determine the password in the RFC because NW04s systems are case-sensitive with passwords.

Message was edited by:

Keerti Vemulapalli

Message was edited by:

Keerti Vemulapalli

Go to solution
WolfgangJanzen
Product and Topic Expert
Product and Topic Expert
In response to Former Member

‎11-09-2007 8:52 AM

0 Kudos

Hi Keerti,

thanks for mentioning about NW04s / NW7.0 (basis for ERP 6.0 and various other ABAP-based products). I only want to add some links to relevant / useful SAP Notes:

- <a href="https://service.sap.com/sap/support/notes/1023437">SAP Note 1023437</a> (explaination: downwards-incompatible passwords)

- <a href="https://service.sap.com/sap/support/notes/862989">SAP Note 862989</a> (overview: new features / changes with NW04s)

- <a href="https://service.sap.com/sap/support/notes/495911">SAP Note 495911</a> (How to analyse logon problems)

- <a href="https://service.sap.com/sap/support/notes/622464">SAP Note 622464</a> (overview: usertypes and their impacts on security)

Regards, Wolfgang

PS: it is generally recommended to assign the usertype SYSTEM (instead of COMMUNICATION) to those users whose logon data is stored in remote systems' destinations.