I was wondering if there is an already deployed feature in Jfrog Artifactory that stores the user's password history.
I would like to have the ability to reject a password which is the same with some that has been used in the resent past.
One solution that I thought is a custom implementation which will query the password history of a user from the MySql database and search in the reults for the given password.
I am using the 6.3.3 version of Jfrog Artifactory.
That feature doesn't exist as far as I know in Artifactory today, if you're configuring the users in Artifactory itself. If you're using an external user store (like LDAP), you could set those rules there.
JFrog Access provides some password policy rules (see here). But Artifactory does not persist passwords (or old passwords) due to security considerations.
You might argue such a feature can be implemented with password hashes which is correct, but no such thing is currently implemented - you can always submit a feature request
Related
For a school I implemented eduroam two years ago and from time to time we add new students in the AD.
Five days ago I added 40 more new students but I changed the CN's (or what in New-ADUser is called "-Name") format:
from "name.surname" to "SURNAME, NAME" (quotes excluded), hence
earlier it was
CN=name.surname, OU=CLASS_A, OU=STUDENTS, DC...
now it is
CN=SURNAME, NAME, OU=CLASS_A, OU=STUDENTS, DC...
an eduroam's username normally is <string with no blanks>#<yourschool>.<tld> so that the RADIUS proxies can route the auth request based on #<yourschool>.<tld> , So I must keep such a format.
Now, the new users cannot be authenticated anymore by NPS.
All the tests I ran back my thesis (i.e. that NPS uses CN to authenticate) but I cannot find any Microsoft document that states that.
Could anybody share the link to such doc?
is it a way to change the check from CN (if proved by answer of point 1)) to another user's recor like sAMAccountNAme or UPN?
I'm sure I'm touching something deep in AD but I hope somebody has tripped into this issue and has found a answer.
TIA
P.S. I guess the alternative would be to use FreeRADIUS but I would rather explore the options to still make within NPS/AD
• Please check the Windows Server event security log for more details on the issue for NPS authentication because that might shed some more light on the actual issue that you might be facing. Till then, please clear the cache and temporary files from the server and restart the whole infrastructure regarding NPS, i.e., domain controller, NPS Server, Access points and other related devices through which users can login through NPS.
• Once restarted, please try to authenticate any allowed user through NPS once again and check. Also, as you are using NPS as a radius server proxy, please check for the attribute manipulation rules for message forwarding since the CNs are changed in their order/format in your AD. Specifically, regarding the username which is provided by the access client and is included by the NAS in the Radius access-request message. The value of this attribute is a character string that typically contains a realm name and a user account name.
• To correctly replace or convert realm names in the username of a connection request, you must configure attribute manipulation rules for the User-Name attribute on the appropriate connection request policy.
Also, find the below links regarding your query whether which attribute you can use to authenticate in case of NPS. In it, it clearly stated that user principal name should be used as an attribute as a best practice: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#performance-tuning-nps
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-best-practices#using-nps-in-large-organizations
Please check the below documentation link for your condition: -
https://learn.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-plan-proxy#key-steps-3
I'm trying to login into my staging Salesforce lightning, by I get the following result:
INVALID_LOGIN: Invalid username, password, security token; or user locked out.
I use the 'jsForce' library version 2, with the right serverUrl, username and password+token combination.
Note that when I do exactly the same for my production Salesforce environment - I succeed.
Any suggestion to why there's a difference between staging and production - would be helpful.
"exactly the same" to prod is probably bad idea, https://test.salesforce.com vs https://login.salesforce.com ;) And even if you have same password - the token could be different, password could have expired.
Do you see anything in the user's login history in setup? It's hard to guess these things. Do you get same result if you try SOAP API login or OAuth2? Or even plain old SF Data Loader?
Maybe admin went to Setup -> My Domain and disabled logging in from generic address, forcing you to go https://mydomain--mysandboxname.my.salesforce.com/... ?
Maybe admin enforced Single Sign-On on everybody and you can't use SF username & pass anymore.
There might be restricted IP addresses or login hours set
Found a Solution: when logging to Salesforce using the jsForce libray, only the 'loginUrl' parameter works as expected (as opposed to 'serverUrl' for production).
"Issue description copied..."
I'm building a partner connector, which relies on a user name and password to connect to database (very similar to the existing Postgres / MySQL connectors provided by Google). In order to verify the credentials, I also need the database host information to be present in addition to username and password and this is the base of my problem.
The Google build connectors conveniently are allowed to collect user credentials and the database related information at the same time. Unfortunately, that doesn't seem to be the case for partner connectors as stated in the requirements
Point 5 "Use appropriate authentication method in getAuthType(). Do not request credentials via getConfig()."
The authentication itself happens before any other configuration details are known (there is just a dialog for username and password) and there doesn't seem to be a way to request additional information on the authentication screen itself. Once the credentials have been entered, the verification also happens immediately, before the configuration is being shown in the next step.
Once credentials are validated successfully, Datastudio then assumes the schema and data can be requested.This excludes the option of a dummy confirmation, because there doesn't seem to be a way to tell credentials are invalid and need to be changed after checking the other configuration details on the next screen.
That makes me unsure, how to determine valid credentials in my use case as I need to know the variable endpoint to authenticate against. I definitely want to avoid storing any user credentials myself in an external database, because this opens up another can of worms.
Has anyone successfully solved a similar issue before and can provide guidance here?
This is a known limitation of the authentication methods for Community Connectors.
A workaround would be to use authtype NONE and then request the credentials and database information in the config. This is, however, not a recommended approach.
If a user logs in to their computer using a Single Sign-On system such as Active Directory, LDAP, or Kerberos, is it possible for applications they run to know who they are and what system they authenticated with? Can I get enough information out of these systems to verify their identity without requiring any additional user input?
Specifically, I would like to be able to check these things:
Did they log in via a single sign-on system at all, or are they just using a regular user account on this machine?
What system did they use?
Does the system have some URI that would distinguish it from any other directory?
What is the current user's distinguished name in that directory?
Can I get some information which I can pass to another host to prove to that host that the user is who they said they are? For example, a token that can be used to query the SSO system.
I'd assume all of these things should be possible, and in fact encouraged, but I am not positive. I'm sure the method of getting at this information is
SSO (at least with Kerberos which is used by ActiveDirectoy) is based on a token. As soon as the user requests access to a kerberized system the system queries for the token and checks its validity for accessing the system. It's as good as querying for username and password. when the user did not log in with an Kerberos-account there is no tiket so no automated access.
using the token you can get the users login- name and from that you can then use that to query the SSO-backend (typically LDAP) for more information on that user.
LDAP is not an SSO-system as it is simply a storage query protocol but it is often used as backend for SSO-systems.
The problem often is kerberizing an application. for Webapps that means you have to kerberize the webserver so that that one then can handle the authentication process with the SSO-service and then pass that information on to the unferlying webapp.
Hope that answers you questions.
for more information have a look around the web for kerberos
You are really asking about two things:
Authentication: Who are you?
Authorization: What are you allowed to do?
Kerberos really only answers the first question, you need a secondary system like LDAP or Active Directory ( which is both kerberos and ldap in a single server) to answer the second.
If your system is using kerberos correctly, any user login should have an associated kerberos ticket. With this ticket, you can request "service" tickets
to prove your identity to remote servers that support kerberos. The ticket
contains your principal identity in the realm ( user#DOMAIN.NET ) that can be
used to query authorization systems.
However, the details required to get all the moving parts in that sentence working together "on the same page" so to speak can be very complex. The remote service has to support accepting kerberos credentials, it has to be either in the same realm or have a cross realm trust relationship configured.... The list
gets pretty long. Depending on your exact application environment, using all these things can be fairly trivial, or it can be next to impossible.
i'm developing a .net winforms desktop application intended to be run at several bank's branches as a backup application whenever the main one (a web application) is unavailable due to connection issues with the bank's central node. The branchs themselves don't count with any enterprise services besides a SQL-Server database. For that reason, the application should be able to connect directly to the SQL-Server. My problem arises when I have to provide the application with a password to connect to the database:
1) Storing the password in clear text in a app.config file or similar is not an option (the customer requires the password to be encrypted)
2) Storing the password encrypted in a configuration file leads to the need of having an encryption key locally available. The encryption key could be just hardcoded in the application's code, but it would be easily readable by using a .net-decompiler or similar.
3) Using a custom algorithm to encrypt/decrypt wouldn't work either due to the same reasons as 2).
4) Integrated security is not supported by the bank
Additionally, the customers requires that they should be able to change the password in one location (within a branch) without the need to go from one computer to another updating config files (that rules out the possibility of using the machine's key to encrypt the password in individual machine's config files like asp.net does)
Would you provide any other approach or suggestion to deal with this problem?
I would appreciate any help.
Thanks in advance,
Bernabé
I don't think that encyrpting the password by any means is going to solve your problem. If the user has to send the password to server, and the password is located on the box, then by definition the user running the application must have access to the password and be able to decrypt it. Otherwise, you wouldn't be able to authenticate them. This means that there will always be a way for the user to get at the password, regardless of where you store it.
I can think of 2 ways that could possibly work, but I'm afraid they're not exactly what you're looking for.
Remove the requirement of having the
user send the password to the server
by using some sort of local proxy
(for example using a WCF windows
service) to take your winform
requests and then send them on your
behalf to the DB server. If you
install the service using an account
different from the user's account,
then you can secure the password by
any of the means mentioned in the other
answers. They key here is to make
sure the application user does not
have access to the resources that
the service account needs to decrypt
the password.
Don't store the password in the web config. Assign each user a different user account and password at the database level and have them type it in when they log in.
You could use the protected configuration built into .Net. See Encrypting Configuration Information Using Protected Configuration in the MSDN docs. One of it's raison d'etres was to encrypt data such as connection strings in config files.
You could
To use DPAPI to store a encryption/decryption key securely: How To: Use DPAPI to Encrypt and Decrypt Data
To install a SQL Server Compact Edition (or another small database) into your workstations and to synchronize data when your web application comes online again.
To ask for help inside that institution, as other people could have solved that problem and could to help you.
Definitely agree with the above regarding DPAPI. Microsoft's Enterprise Library makes this an absolute breeze too, so I would consider looking there first.