I'm working on a spring(IoC/ MVC/ Security)/ JTOpen project backed up by DB2 over IBM System i (AS/400). For reasons I won't be able to discuss here, every user of the application was given an account on the IBM i (i5/OS) operating system so that his transactions get logged against his identity in the Journal (DB2 log files). In order to achieve that we have been establishing a connection once someone logs into the system using his credentials and accordingly getting his transactions against his name in the Journal.
Problem:
Recently, we have been investigating on getting a connection pool in place instead of the status quo of connection per session. If the pool establishes these connections once the application starts using a generic i5/OS account, say: SystemAccount, then a user logs in a requests one of these connections, is there any way to execute transactions under the identity of the user although it was established using the generic system account?
The com.ibm.as400.security.auth package provides classes that allow user profile swapping using IBM i profile token and credential classes when using the AS400 connection class.
If you are using JDBC you can call the Security-related APIs to adopt profiles on the connection.
Get Profile Handle (QSYGETPH) validates a user ID and password, and creates an encrypted abbreviation called a profile handle for that user profile.
Set Profile Handle (QWTSETP) switches the job to run under a new profile.
Generate Profile Token (QSYGENPT) verifies that the caller has authority to generate a profile token for the requested profile and then generates a profile token.
Set To Profile Token (QSYSETPT) validates the profile token and changes the current thread to run under the user and group profiles represented by the profile token.
Have you verified that the transactions are actually being improperly logged? I wouldn't expect them to be.
Related
I need your help if possible in order to resolve the issue mentioned in message subject. I have a TFS installation in two servers: one for application and another for database both on AD Domain. For security reasons I need to change the domain user account password used for this application (the user account is the AD Domain Administrator).
I changed the password from Windows AD users and computers console and after that when I tried to access to TFS (http://servername:port/tfs) I received the TF246017 error. I restored the old password for the account and TFS started to work again.
I saw that this domain user account figures in TFS Admin console, under application tier and there is an option to upgrade the password of service Account. My questions are if it is necessary to run password upgrade from there in addition to doing it from the administrator of AD users and groups option and if there is/are another option/s that I should take into account to modify the password for this user account.
Thank you in advance for your attention and your help.
Best Regards.
The error info and root cause is very clearly. You need to update the password of your corresponding account.
There are two ways to achieve the account password update:
To use the administration console to change the password
To use the TFSConfig utility to change the password:
To avoid TF246017 Error occur again, I would recommend you use the same user credential for SQL Server and TFS server. Ex: domainname/tfs is local admin to the server, sysadmin in SQL Server DB and also admin user to TFS server.
You could also check the Event log. The Windows Event Log is a good candidate where to look for the potential cause.
You need to use tfsconfig on the app tier server.
Something like tfsconfig accounts /updatepassword /account:[account name] /password:[password] should do the trick.
See also: https://learn.microsoft.com/en-us/vsts/tfs-server/admin/change-service-account-password?view=tfs-2015
For some reason an account which I've registered using my app and tested before is now giving me an error when trying to log in using its details: "Logins don't match. Please include at least one valid login for this identity or identity pool."
I know the values I am using for it are definitely correct and other accounts are still able to login. What could be the cause of this error?
Any help would be greatly appreciated.
What the SDK is trying to tell you is that the identityId in your Federated Identity Pool (and which may be stored in a keychain in your device, and which may be re-established on restart from an existing session) does not match the login in your authentication provider which was returned by the "logins" method.
This can happen in a number of different ways, but this usually occurs because you attempt to log in as another user on the same authentication provider without first logging out.
The SDK recovers by retrying.
(This recovery does not really work because I think it takes 2 or 3 attempts to time out, and the recovery then leaves you in a state where subsequent logins fail with the same error. Restarting the app clears this. I have not fully investigated the defect in the retry/recovery process)
The solution is to prevent the app from logging in on a different ID with the same authentication provider (IdP) without first logging out of that authentication provider.
When using LogonUser() with LOGON32_LOGON_NETWORK to validate a user's Windows login and password, it does not seem to cause their account to be locked even if the wrong password is checked more times than the user's security policy allows.
There is a similar question:
Incorrect password passed to LogonUser() but the Active Directory account is not locked as expected
But in their case, they were using LOGON32_LOGON_INTERACTIVE instead.
In my case, the domain controller is available to authenticate the logon, but it is not clear from the documentation whether using LOGON32_LOGON_NETWORK means it does not authenticate with the domain controller, only that it will not cache the credentials if they are correct.
What I'm looking for is a policy setting that will lock a Windows domain account if LogonUser() is used with the wrong password too many times.
EDIT: Additional information to help clarify the situation.
When calling LoginUser() on my XE2 development machine with the correct domain\user but incorrect password, the result is false. Calling SysUtils.SysErrorMessage(System.GetLastError) gives me:
The operation completed successfully
The same test performed on any of the machines at the client site shows:
Logon failure: unknown user name or bad password
Continuing the test on any of their machines eventually has it reporting:
The referenced account is currently locked out and may not be logged on to
What I am trying to determine is why that client is behaving differently, as we'd like to have systems on our domain also lock accounts. Perhaps it is a property of the Windows account?
The policy setting you are looking for is the Account Lockout Threshold.
I don't believe this has anything what-so-ever to do with the fact that Delphi is the language involved in calling the API. This is purely a Windows API / security policy question.
I'm just getting started with D2L and am running into problems.
On the "Getting Started" page, I have completed the first three steps:
1) Acquire an App Key/ID pair from D2L - I have received the App ID and App Key
2) Create a test account in your host LMS - I have created a new user account with the administrator role for testing
3) Choose a client library to work with - I am using the PHP SDK
4) Authenticate with your LMS - This is where I'm running into trouble.
When I use the Getting Started sample:
http://samples.valence.desire2learn.com/samples/GettingStartedSample/
And enter my host, app ID and app key and hit on the "Authenticate" button, I get a "This application is not authorized on this LMS instance. Ask your administrator to authorize this application" error.
I am an administrator on my D2L host and I'm not sure how to authorize my own app.
I have tried the following:
Navigating to the "Manage Extensibility" page because that's where D2L says my app should be located, but it isn't there.
Enabling the API (d2l.Security.Api.EnableApi) under the "DOME" page to no avail.
What am I doing wrong?
Based on your question and comments, there were two issues here:
First is that the list of App ID/Key pairs appropriate for your LMS get regularly fetched by your LMS from the D2L KeyTool service. The schedule for this fetching is once a day; accordingly, if the scheduled task isn't set up, or if your LMS isn't identifying itself properly to the KeyTool service, or if time hasn't yet elapsed after key granting to the next scheduled run of the task, the App won't yet be in your LMS' Manage Extensibility list. It sounds like you no longer have that issue.
Second is that the Valence Learning Framework APIs' authentication process (requesting and retrieving a set of user tokens for an LMS user) requires several LMS features to be properly set up: (a) the LMS must be configured to support Deep Linking, (b) the LMS must be set up to handle the ?target= parameter on incoming client URL requests, and curate that parameter throughout the user authentication process.
In cases where your LMS is not doing the user authentication but depending upon another, third-party IDP (like Shibboleth), any ?target= parameter passed into the login process must be taken care of by the IDP and properly handed back to the LMS after user authentication. In a situation where you have multiple redirections occurring during user authentication, this can involve successive generation of a target parameter, and each generation must re-URL-encode the previous request URL in its entirety (like sticking an envelope inside another envelope, inside yet another envelope).
If your LMS is not properly configured to support these two points, which you might not notice during other operations, then client calls to the Learning Framework APIs won't work because the calling client won't be able to fetch back a set of user tokens.
To solve the second of these issues, you may have to contact D2L's Customer Support desk -- they can verify, and adjust as necessary, the LMS configuration part of this authentication chain. If you're integrating your LMS with other third-party IDP components not administered or deployed by D2L, then you might also need to adjust their configurations: D2L can likely advise on what needs to be done there (curate the target parameter on URls), but cannot adjust the configuration for you in those cases.
I need to establish a HTTPS 2-way SSL connection from my iPhone application to the customer's server.
However I don't see any secure way to deliver the client side certificates to the application (it's an e-banking app, so security is really an issue).
From what I have found so far the only way that the app would be able to access the certificate is to provide it pre-bundeled with the application itself, or expose an URL from which it could be fetched (IPhone app with SSL client certs).
The thing is that neither of this two ways prevent some third party to get the certificate, which if accepted as a risk eliminates the need for 2-way SSL (since anyone can have the client certificate).
The whole security protocol should look like this:
- HTTPS 2-way SSL to authenticate the application
- OTP (token) based user registration (client side key pair generated at this step)
- SOAP / WSS XML-Signature (requests signed by the keys generated earlier)
Any idea on how to establish the first layer of security (HTTPS) ?
Ok, so to answer my own question...
It turned out that the security has no fixed scale of measurement.
The security requirements are satisfied as long as the price for braking the system is significantly above the prize that one would get for doing so.
In my situation we are talking about e-banking system, but with somewhat low monthly limits (couple of thousands USD).
As I mentioned in my question there would be another layer of security above the HTTPS which will feature WSS XML-Signatures. The process of registering the user and accepting the his public key is also done in several steps. In the first step the user sends his telephone number together with a cod retrieved somehow from my client. Then an SMS is sent to the user with a confirmation code. The user enters the confirmation code into a OTP calculator that would produce OTP code which will identify the user. Then the public key is sent to the server together with the OTP code. From here on every request would be signed by the private counterpart of the public key sent to the server earlier.
So the biggest weakness for the whole process is that of someone reverse engineers the application and retrieves the client certificate used for the SLL. The only problem arising from this is that someone might observe users' transactions. However in order for someone to make a transaction he would need the user's private key, which is generated, encrypted and stored into the keychain. And the price for braking this security level is VERY HIGH.
We will additionally think on how to protect the users' data on a higher level (e.g. using WSS Encryption), but for the start I thing we are good with the current solution.
any opinion ?
regards
https doesn't really work this way. In a nutshell, you attach to a secure server where the certificates are signed by a well known authority.
If you use Apples (iPhone) classes for this, they will only accept 'good' certificates. By good, I mean what Apple deems as acceptable. If you don't use them (there are alternatives in the SDK), you won't be able to connect (except, maybe, in the case where you have an 'Enterprise' developers license - but I can't say that with 100% certainty as I haven't looked enough at this license to be sure)
To continue, use your https connection to your correctly signed website and then institute some sort of login with a built in username/password, or challenge/response based upon the unique ID of the iPhone (for example) and exchange keys using that connection.
Note that this means that your application will have to query for new certificates at (each connection/every X connections/every month/application specified intervals) to keep them up to date. You can then use these certificates to connect to the more secure server.
[edit]
Check this post - may have more information about what you're asking to do
[/edit]
[edit2]
Please note that the request is iphone, not OSX - app store approval is an issue
[/edit2]