Thycotic Community - Secret Server - Feature Request: Secret Validation - Messages

Message from Jonathan

Tue, 06 Dec 2011 19:34:23 GMT

A great tool to test out your Regex is Expresso (free Windows tool).

Here is a Regex that should meet your needs:
^(DEV|TST|PRD|ENT)\s*-\s*[^-]+\s*-\s*[\d]{1,3}$

It will allow stuff like:
DEV - My Server! - 001
But not:
DEV My Server! - 001 (the dashes are required)
It also doesn't really understand 255 - it will accept up to 999 (hard to do in Regex).

Make sure you put a good "Name Pattern Error Message" in Secret Server so your users understand the format they are supposed to be following as it won't let them save the Secret unless the format matches the Regex.

This is a good site for exploring Regex and getting ideas/help.
http://regexlib.com

Message from Nick D

Tue, 06 Dec 2011 15:46:08 GMT

To be more specific, i want this. A secret that starts with either DEV, TST, PRD, or ENT - some text - a number from 0-255

Example: DEV-ADC-01

I've established [De][Ee][Vv]|[Tt][Ss][Tt]|[Pp][Rr][Dd]|[Ee][Nn][Tt]

Message from Nick D

Tue, 06 Dec 2011 14:29:17 GMT

Thanks Jon! I think I can work with some of these. Would it be possible for someone to help me with a regex example, if possible?

How could I write a regex to say that the start of the secret name must either contain DEV, TEST, PRD, or ENT (case not an issue)

Message from Jonathan

Tue, 06 Dec 2011 12:53:41 GMT

Good discussion!

A few options that exist today:

1) Naming Pattern
This lets you set a Regex at the Secret Template level to force all Secret Names to follow a certain format (only text rules though not semantic)
http://updates.thycotic.net/secretserver/documents/SecretServerUserGuide.pdf?#page=25

2) Heartbeat
Turning on heartbeat for Secrets can help to find if two Secrets exist for the same credential. When the password on one changes, the other will fail heartbeat and vice versa. Not perfect but helps to track down issues.

3) Discovery
Secret Server can look at AD (multiple domains supported) and find machines in the domain. It can then check those machines for local accounts and then map those to Secrets. This can be used to find accounts mapped or not mapped to Secrets.
http://www.thycotic.com/products_secretserver_discovery.html
This feature is being extended to more platforms than just AD such as UNIX/Linux, Network equipment, databases, etc.

4) Report to find duplicate Secret Names
Just create this report in your Secret Server to find Secrets with duplicate Secret Names (requires Enterprise or Enterprise Plus Edition to create custom reports).
http://www.thycotic.com/products_secretserver_customreportgalleryview.html?reportId=398

Hope those are helpful.

:-D

Message from Nick D

Tue, 06 Dec 2011 10:14:59 GMT

Voting is good, but that requires people to actually vote...something many people dont want to do. They want to get in and get out. I like the idea but (for us at least) it wont solve a problem.

Perhaps name validation should be an option that can be toggled, and I'm thinking something very basic, just check for the same name, without regard to case sensativity.

Does another secret with the name "SecretABC" exist? It can be SeCrETaBc, or secRETaBC...etc. We are looking to implement a standard for naming here, because afterall the name of a secret can be different than the username in the secret. It's a common misunderstanding here that people will name the secret by the username (i.e. administrator) rather than a descriptive or standard name. We would use something like "Environment" - "Device" - "username"

So something like "DEV-ADC-ADMINISTRATOR" would be the Administrator account on the Active Directory Controller on Development.

Of course we would fine tune the naming standard to prevent any redundancy.

The goal, Secret Server needs a way for any user to query all secrets, even those that the user does not have access to, so they can see if a secret exists. If they see a secret exists that they need access to, they can either request it or use the built in request functionality.

Another feature request would be the ability to flag a secret with an owner that a report can be run on. It would be nice for a user to run a report for any secret that exists with say the word administrator in it, and also see a note that says "the Networking team owns this secret, for access see them"

Message from Larry

Tue, 06 Dec 2011 09:07:33 GMT

Ha another thought about voting on a secret's value and encouraging users to participate. Read this recently on a startup's website - thought I would share:

---
Charles Schwab had a mill manager whose people weren’t producing their quota. “How is it that a manager as capable as you can’t make this mill turn out what it should?”
“I don’t know,” the manager replied. “I’ve coaxed the men, I’ve pushed them, I’ve sworn and cussed, I’ve threatened them with damnation and being fired. But nothing works. They just won’t produce.”
Schwab asked the manager for a piece of chalk, and asked: “How many heats did your shift make today?”
“Six.”
Schwab chalked a big figure six on the floor. When the night shift came in, they saw the “6? and asked what it meant.
“The big boss was in here today, he asked us how many heats we made, and we told him six. He chalked it down on the floor.”
The next morning Schwab walked through the mill again. The night shift had rubbed out “6? and replaced it with a big “7.”
When the day shift reported for work the next morning, they saw a big “7? chalked on the floor. So the night shift thought they were better than the day shift did they? Well, they would show the night shift a thing or two. The crew pitched in with enthusiasm, and when they quit that night, they left behind them an enormous, swaggering “10.”

http://objectivelogistics.com/theory/
---

Message from Larry

Tue, 06 Dec 2011 09:02:23 GMT

This sounds like a good feature.

My thought on this is that it would be difficult for a search engine to spot duplicates, our team gets pretty creative with naming conventions.

One possible way to overcome this is an option to both track usage and vote on accuracy.

A secret that is used more often might 'rise to the top' when sorted by usage.

Another idea is to have a way to "vote" on the accuracy of secret. maybe a 1-5 scale:

1 = suspected of being inaccurate
2 = Possible duplicate
3 = Poorly Documented
4 = Good
5 = Excellent

Just sharing some thoughts,

Larry

Message from Nick D

Tue, 06 Dec 2011 08:45:48 GMT

I don't know how other companies handle this, but the biggest drawback to Secret Server we have found is redundant secrets because someone created a secret that already exists because they didn't know it already existed or they don't have access to it. Secret Server can get messy quickly.

We were thinking of a way to help resolve that. The first thing which we can do as a business process is to have a naming standard for all secrets. This can be monitored by a team that gets alerts when new secrets are created and if they dont conform to the naming standard we put in place they inform the creator to change the name.

The next thing (feature request) would be if Secret server could do some sort of validation of the secret name against all other secrets. If another secret exists with the same name they get an error that it already exists. This would be a huge win for us.

Thoughts? or maybe people can tell me how they handle redundant secrets in secret server when using many ACL's and AD users/groups?