So I have a webapp that manages my rust servers. I need to provide the rcon password in order to use rcon. But for that I need to store the password in my database.
Is there an alternative way to make a connection to rcon, like using OAuth tokens or anything that I'm not aware of? Without saving the password that is a major security issue.
Rust Servers (The game) uses a websocket server for the rcon and does not support OAuth. So NO. There is no alternative method authenticating as the password is expected as a path in the websocket connection URL.
ws://ip:port/password
Related
In Azure DevOps services, when you connect an agent to the server, you have different types of ways to authenticate to the server. You can see here for example, about connecting a Linux agent, that you have these 4 types:
Alternate (Basic authentication)
PAT
Negotiate - Connect as a user other than the signed-in user via a scheme such as Kerberos or NTLM.
Integrated - Not supported in Linux
The integrated type is mentioned in the page about connecting a Windows agent as "Windows default credentials"
Bare with me please.
In my organization, we have a Active Directory domain with a Single-Sign-On, I suppose it uses Kerberos as the authentication protocol. Sometimes I use Powershell scripts to access the API of our internal Azure DevOps Server, and I use the -UseDefaultCredentials flag so the user won't have to enter username and password - it will just authenticate based on the logged-in user.
That got me thinking that the -UseDefaultCredentials flag is using Kerberos to authenticate.
But from the above, it seems that Integrated is using "Default credentials", which is something else than "Negotiate" which uses Kerberos.
Can someone help me understand this?
The UseDefaultCredentials flag tells the underlying system to try and use the caller's SSO credentials, which in most cases is the credential used to log into the system interactively or otherwise.
Strictly speaking it does not indicate which protocol to use. What it's actually saying is "dear system internals: please figure it out for me". The way this works is by selecting the negotiate protocol, which as it's name suggests negotiates the use of specific authentication protocols based on the client credentials as well as information from the server. This is called the SPNEGO protocol. It is transparent to the caller.
SPNEGO is fairly simple in nature. The client has a list of known authentication protocols (Kerberos, NTLM, etc.) and will send that list to the server saying 'pick one please'. The server can select any of them and respond telling them what to use, and the client then goes and uses it. Fin.
SPNEGO is also relatively smart because it can reasonably predict what it thinks the server will accept and will attempt to optimistically provide a token up front using the first protocol in the list. So if it thinks it needs Kerberos it'll go and get a Kerberos ticket up front and send it first. The server might think that's fine, or it might fail and return a response saying
"no, I really need NTLM", and so the client tries again with NTLM.
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
We are in the planning phase of configuring our soon-to-be-upgraded databases (19c) to authenticate directly against AD (no oracle proxy). I have read a handful of documents from Oracle on how to do this. Most of the documentation focuses around using passwords (password filter/verifier). The only problem is that our AD administrators are dead-set against implementing Oracle's password filter into our existing AD infrastructure. That being said, one of the security guys said we could implement the oracle authentication using Kerberos instead. From what I have read, and the documents are scattered all over the place, and nothing that detailed, to use Kerberos:
1) The client no longer uses a username/password - they connect using a wallet-style connection (e.g. /#dbname)
2) Not only does the Oracle DB need some configuration changes, but so does every client that plans on using Kerberos
I don't know anything about Kerberos, how it works, and what goes on when you implement this, but I was hoping for, at the end of this is:
1) No client changes/installs (only the oracle DB would have config changes)
The user will continue to provide credentials as before - completely transparent
2) No need for the password filter as our admins have a "beef" against it
So my question is:
If using Kerberos directly against AD on >=18c:
1) Does the client user still provide a username and password to authenticate against AD, or does the client simply get "accepted" due to the tickets/tokens/configuration that occurs on the client (i.e. the client is simply trusted)?
2) Is there client config changes that need to occur, or does the client reach out to the DB and the DB, with its config changes, does all the legwork to authenticate against AD based off of client info being passed
3) Does any additional manual component need to occur on occasion (periodically retrieving a ticket/token/something) (because, say, it expires)
So in the end, we want to have complete transparency with every client and using something other than the password verifier with AD.
Thanks in advance.
-Jim
It sounds like you want to authenticate Windows clients against an Oracle database over a network using Active Directory without making any client changes.
This is pretty open-ended and complex StackOverflow question.
Probably you've been reading the docs about Third Party Network Authentication using Oracle Advanced Security. You can use Kerberos, SSL, RADIUS, PKI, etc. For most of these options, you need to do some setup on the client, because both the Oracle client and server need to authenticate or verify with the third-party system.
I think you need Enterprise User Security (using Oracle Internet Directory). Assuming you go with password-based authentication, you don't need client changes. In this scenario, Oracle Internet Directory can synchronize its user directory with AD, so your users can use their same username/password. However, when they change their AD password, they'll need to change their Oracle password separately.
On a different note, you may be able to alleviate your AD admins' fears about Oracle password complexity requirements, since you can change or remove those to fit your AD requirements.
In a corporate desktop scenario, where the user is logged in to an Active Directory domain, I'd like my application to issue HTTP requests using the same proxy as Internet Explorer uses. The problem is that the proxy requires NTLM authentication using the credentials of the currently logged in user, which is something I don't know how my application could acquire.
Besides asking the user for his/her password (for which I found a lot of solutions), is there a way to do it the right, like using some native API? I'm not picky about programming languages in this case, if it works in this scenario, I accept it, although I'd prefer C/C++.
Since you are on Windows, and you are using domain logins, you should rather rely on Kerberos. Anyway, you now several options:
If you use WinHTTP , you simple have to enable it.
Use libcurl on Windows and it will compile with SSPI support by default.
If you use sockets by yourself, you have to call SSPI with the Negotiate package and exchange tokens per HTTP all by yourself.
I work as a student web developer for my computer science department and I've been asked to look into a modification of our password reset procedure for linux accounts. Currently users will log in with their university credentials (via Active Directory) and after being authenticated they get a temporary password through email which they are forced to change as soon as they log in. This way eben if the temporary password it intercepted there is a very short time span in which it could even be used.
Now the idea has been posed that instead of using a temporary password that we might allow the user to pick a new permanent password and set it directly through the web utility. It is my understanding that https is more of "the best we have" than "a great way to secure information". Are there any other avenues I can explore for securing the new password so that we can feel comfortable implementing such a system?
Basically, if you communicate with a server over HTTPS and the private key of the server isn't exposed to someone else, you can be sure that anything you transfer (e.g. the new password) can only be decrypted by the server. Additionally the server certificate assures, that the server you are communicating with, really is the server you want to communicate with.
So, using HTTPS provides authentication and prevents eavesdropping.
If you are working with Active Directory, it is my understanding that the Password Modify Extended Operation (which requires the existing password) is not supported. Therefore, the password must be changed with the LDAP modify request. One solution would be to use the UnboundID LDAP SDK with a web application to execute the LDAP modify with the new password. The modify request should be transmitted over a secure connection, or a non-secure connection promoted to a secure connection using the StartTLS extended operation.
see also
AD password change
Using ldapmodify - this article is about the command line utility ldapmodify but the concepts are useful.