I have a issue in which i have to pass the Navision Login Userid and password from navision to .Net Dll. As parameters.But my problem is i am not able to get the password.
Can anyone suggest how can i get login password in Navision.
With Windows Authentication you don’t even need to know user’s credentials at all - Win manages access rights, especially if the other side is .net based. DB authentication may be a problem here - but which one do you use?
I am Using SQL SERVER 2005 DATABASE.But Without passing Password into dll i will not be able to get the data as SQL Authentication is done for userid and password.
Try connection.ConnectionString = “Server=NAVISION; Database=YourDataBase; Integrated Security=SSPI; Type System Version=SQL Server 2005” connection.Open()
Well, then it’s a problem - passwords are stored in SQL in encrypted form, you can’t get them programmaticaly in usable form (IMHO MSSQL ver.6.5 was the last one including special function which returned dechipered user’s password, it’s removed now).
Do you have some serious reasons not to change from Database to Windows authentication? The latter is more “advanced” and easier to use anyway…
If you mean SQL Roles - where do you see the reason you can’t create these for Windows Users?
These are absolutely unlinked things - method of authentication is separate from what you do with the User accounts further, including granting them different rights, assigning roles etc. etc.
The Integrated Security = SSPI in DLL Connection string is working fine now.
But there is another issue
When i write the Integrated Security = SSPI in Navision C/AL code it is not working.Showing Connection error.
But i have written Persist Security Info=FALSE;’ instead of Integrated Security = SSPI , then it is working fine.Will there be any issue regarding securtiy of data or any other type while using Persist Security Info=FALSE;’
Once more - there is no difference, HOW you authorise access, by means of which method. These are only different ways of “unlocking the door”, once you are in, you are treated the same.
Additionaly, all security issues are managed inside your .dll (it creates connection to SQL, as I understood). And, when this .dll is called, it’s done in current user context - if the user is not authorized in SQL, your .dll simply won’t connect. BTW, you should handle this exception in your .dll (i.e. with Try/Catch structure), otherwise occasional call to .dll by unauthorised user will end up with unhandled error and crash…