I'm using an HDFS keytab to perform certain superuser operations on an API call. The keytabs change roughly every 6 months, sometimes more frequently if a breach occurs. Whenever this happens, my application needs to fetch the latest keytabs from a remote host over SSH.
For performance reasons, on each API call, I would like to determine if the existing keytab is still valid and current. (If not, there's no need to fetch it.) One way to do is to try using the keytab, and if an exception is thrown, fetch the new keytab. However, I don't like this approach because I understand that using exception handling to control flow is an anti-pattern.
Ideally, I would query some sort of API to check the current keytab's validity, and only fetch the latest keytab if necessary. Do the UserGroupInformation Java APIs provide a way to do this?
Related
I have set up a OIDC on my nifi standalone instance, it works great and all but if i idle for more than 5 mintues it redirects me to an Unauthorized window message and says
"Unknown user with identity anonymous".
Refreshing solves this, however, is there a way to make sure to extend the connection, or a workaround to avoid these disconnects?
In case anyone is struck with a similar problem,
my solution is to overwrite the NAR file responsible to OIDCAuthentication (just increasing the expiration timer hehe)
its not a pleasant solution but it will do for the time being, until nifi supports refresh tokens or adds a feature to customize session duration.
stay updated at
https://issues.apache.org/jira/browse/NIFI-4890
It depends on used Identity Provider (IdP) - it generates token with preconfigured time validity. Usually, it can be configured on the client configuration level, but it is recommended to have short time validity. OIDC offers option how to renew access token, but it depends on used flow. It can be refreshed via refresh tokens (grant code flow) or silent refresh (implicit flow). It is not clear which IdP and flow is used in your case, so you can get only these general recommendation.
How to use security in SD synchronization without GAM?
I need to block unwanted connections. How can I validate the execution of
Synchronization.Send () and Synchronization.Receive ()
I can not use GAM because I have to adapt my application to a pre existing security system.
There is currently no way for sending additional parameters or HTTP headers in the requests, so you'll need other means to identify your user.
One thing you could do, is call a procedure before synchronizing, passing the relevant information to identify the user (an authorization token or something like that). Then, you should validate that the next call is to the synchronization process, and check for instance that the IP address and the "device id" are the same.
Where would you validate the user's information, depends on which synchronization are we talking about.
For the Receive operation, you may perform your validations in the Offline Database object's Start event.
For the Send operation, everything is saved to the database by using Business Components. So you may add your validations in all the BCs that are involved.
Note: having said all the above, it is highly recommended that you use GeneXus Access Manager (a.k.a. GAM), where all this is already solved.
Second note: you should use HTTPS in all your connections; otherwise, none of this will be secure.
I'm using the WNetEnumResource to enumerate all network share connections and WNetCancelConnection2 to close them. Then I am using WNetUseConnection to connect to a share using discrete credentials. This process happens multiple times throughout the day.
The problem that I'm running into is that after the first flow through the process I'm getting:
System Error 1219 has occurred.
Multiple connections to a server or shared resource by the same user,
using more than one user name, are not allowed. Disconnect all
previous connections to the server or shared resource and try again.
This happens even when the enumeration says there are no current connections.
My question is: why? Why am I getting this error? Is the authenticated connection to the server still cached? Can I enumerate these authentication tokens? Kerberos? LSA?
I haven't been able to find the smallest foothold of information to progress forward on this project. Any help is appreciated!
I'm trying to remember the solution we used when we came across this problem for a network backup program a few years ago.
I'm certain the solution involves using either WNetAddConnection2 or WNetAddConnection3 instead of WNetUseConnection. I think that passing the flag CONNECT_CRED_RESET should take care of this, but I'm not absolutely certain.
Note that CONNECT_CRED_RESET is only documented for WNetAddConnection2 and not WNetAddConnection3, though MSDN says the only difference between the two is the hWnd parameter for owner of dialog windows - I'd try with WNetAddConnection2 and only if it works, experiment with WNetAddConnection3. You may even get it to work with WNetUseConnection!
Make sure to note the dependencies CONNECT_CRED_RESET has on other flags.
I have a testing program through which employees can submit JAR files to be executed. This is obviously a security concern, and it gets even worse as the executables have to be trusted since they normally need to access enterprise data.
To that end, I was wondering if it was, at least, possible to use the Windows account of the employee sending the JAR to execute it instead of some surrogate account. Is it somehow possible? What would it imply?
You might want to look into the SSPI functionality of Windows, which may allow you to transparently transfer an authentication token so that you can execute the JAR in the context of the user.
Unless you submit the credentials of the user passing in the JAR file, the saved credential wil not work later on. You might be able to execute it immediately, as long as the sending machine and executing machine are one hop away. Otherwise, the credential will not travel any farther.
I'm using DCOM to provide various application services on a Windows network, using Kerberos to handle authentication. The system normally works fine, but I'm running into issues accessing the service from a separate (trusted) domain. Particularly, the service is unable to make callbacks to the client application, receiving the error "A security package specific error occurred". Also, if I tweak the service to specifically require Kerberos authentication (rather than using SNEGO/negotiate), the client can't even call into the server (again receiving "A security package specific error occurred").
The confusing thing is that things have been working for years without issue. However, a few things are different here, as compared to what we've done before. For one, the servers involved are running Windows 2008, which I have not previously used. Also, as noted above, the errors are only occurring when the service is accessed from an account from a separate domain, and previous usage has never attempted this.
Now to the question: I'm not using an SPN (service principal name) for this DCOM service, but some of the errors and event logs makes me think that might be the problem. However, all the docs I've found are unclear on whether this is correct, or how I would set up the SPN if I do need it. Does anybody know for sure whether an SPN is what I'm missing here? If so, can you point me to how this should be done?
Additional details:
For the scenario where the server is set to force Kerberos authentication, turning on Extended RPC Debugging gives some additional clues. The client can successfully connect using CoCreateInstanceEx, but calls on the service interface fail as noted above. The RPC error records show an error at location 140, and the error code is 0x80090303 ("The specified target is unknown or unreachable"), and the third parameter for that record is an empty string. This points to a missing SPN as the culprit.
For what its worth, Kerberos by definition requires SPNs. You might be able to utilize the built-in SPNS (host/) and the various flavors that host implies (This alias translation is stored in the AD, but for the life of me, I can't seem to find the article listing where this is found).
I'd start by looking at the cross-domain authentication - It can be tricky with kerberos. I'd first turn on full kerberos logging on both the client and server and see if that turns up anything.
Edit: It looks like I may be somewhat mistaken about this. At least one website I found states that DCOM handles SPNs automatically for you (see the bottom of the page), and I confirmed that clients can successfully connect if they demand Kerberos authentication and use "host/[computername]" as the SPN.
It does look like an SPN is required for the service, if you explicitly require Kerberos authentication when calling CoInitializeSecurity in the DCOM server process. For me, the call looked like this:
Warning: Please do not copy this code directly without ensuring that the values are proper for your security needs.
SOLE_AUTHENTICATION_SERVICE sas;
sas.dwAuthnSvc = RPC_C_AUTHN_GSS_KERBEROS;
sas.dwAuthzSvc = RPC_C_AUTHZ_NONE;
sas.pPrincipalName = L"myservice/mymachine";
sas.hr = S_OK;
CoInitializeSecurity( 0, 1, &sas, 0, RPC_C_AUTHN_LEVEL_DEFAULT,
RPC_C_IMP_LEVEL_DEFAULT, 0, EOAC_NONE, 0 );
The SPN can be configured using setspn, as demonstrated below:
setspn -A myservice/mymachine serviceusername
(see the setspn docs for details).
Unfortunately this still didn't solve my problem, but I think the remaining issue is related to some specific problem with the test machines.
I have come across this error while trying to create an instance of the remote COM object. We may face this error If "Delegate" impersonation level is used by the client during the call to CoInitializeSecurity(), and the COM+ service is running under a user account which doesn't have "delegation" permission at the domain level.