store (get and set) data in Active directory , for example connection string
is there a way to store global data (like connect string etc. ) in active directory and get it in c# function ?
somthing like
AD ad = new ...
ad.Save ("MyConnString",connectionString);
ad.get...
c# active-directory
asked Jan 1 at 13:52
mordechaimordechai
5521318
|
show 1 more comment
is there a way to store global data (like connect string etc. ) in active directory and get it in c# function ?
somthing like
AD ad = new ...
ad.Save ("MyConnString",connectionString);
ad.get...
c# active-directory
asked Jan 1 at 13:52
mordechaimordechai
5521318
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
1
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08
|
show 1 more comment
is there a way to store global data (like connect string etc. ) in active directory and get it in c# function ?
somthing like
AD ad = new ...
ad.Save ("MyConnString",connectionString);
ad.get...
c# active-directory
asked Jan 1 at 13:52
mordechaimordechai
5521318
is there a way to store global data (like connect string etc. ) in active directory and get it in c# function ?
somthing like
AD ad = new ...
ad.Save ("MyConnString",connectionString);
ad.get...
c# active-directory
c# active-directory
asked Jan 1 at 13:52
mordechaimordechai
5521318
asked Jan 1 at 13:52
mordechaimordechai
5521318
asked Jan 1 at 13:52
mordechaimordechai
5521318
asked Jan 1 at 13:52
mordechaimordechai
5521318
asked Jan 1 at 13:52
mordechaimordechai
5521318
5521318
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
1
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08
|
show 1 more comment
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
1
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
1
1
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08
|
show 1 more comment
1 Answer
1
active
oldest
votes
This is how you would update a text attribute on an AD object:
var adObj = new DirectoryEntry($"LDAP://{distinguishedName}");
adObj.Properties[attribute].Value = "my connection string";
adObj.CommitChanges();
Actually doing it is the easy part. Planning it will be the harder part.
Active Directory consists of objects with attributes. So yes, you can store text in any text attribute, but you would have to decide:
- Which object you will store the data on (
distinguishedNamein the code), and - Which attribute you will use (
attributein the code)
If the connection string is common for everyone on the domain, you could store it at the root of the domain, but that comes with two problems:
- Permissions to write to the root of the domain are usually only given to domain admins
- There are fewer unused attributes that you could choose from.
If you write the connection string to each user object, then it will be easier to find an unused attribute (if you use Exchange, then there are several that start with extensionAttribute that are often unused), but you are also duplicating that data on every account and you'll have to hope no one changes it.
Like the commenters above, I would suggest you store this somewhere else. If it is a unique connection string per-domain, then you could just store a mapping table (this domain = this connection string). Once the user logs in, you can see which AD domain they're on and grab the correct connection string.
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53996003%2fstore-get-and-set-data-in-active-directory-for-example-connection-string%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is how you would update a text attribute on an AD object:
var adObj = new DirectoryEntry($"LDAP://{distinguishedName}");
adObj.Properties[attribute].Value = "my connection string";
adObj.CommitChanges();
Actually doing it is the easy part. Planning it will be the harder part.
Active Directory consists of objects with attributes. So yes, you can store text in any text attribute, but you would have to decide:
- Which object you will store the data on (
distinguishedNamein the code), and - Which attribute you will use (
attributein the code)
If the connection string is common for everyone on the domain, you could store it at the root of the domain, but that comes with two problems:
- Permissions to write to the root of the domain are usually only given to domain admins
- There are fewer unused attributes that you could choose from.
If you write the connection string to each user object, then it will be easier to find an unused attribute (if you use Exchange, then there are several that start with extensionAttribute that are often unused), but you are also duplicating that data on every account and you'll have to hope no one changes it.
Like the commenters above, I would suggest you store this somewhere else. If it is a unique connection string per-domain, then you could just store a mapping table (this domain = this connection string). Once the user logs in, you can see which AD domain they're on and grab the correct connection string.
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
add a comment |
This is how you would update a text attribute on an AD object:
var adObj = new DirectoryEntry($"LDAP://{distinguishedName}");
adObj.Properties[attribute].Value = "my connection string";
adObj.CommitChanges();
Actually doing it is the easy part. Planning it will be the harder part.
Active Directory consists of objects with attributes. So yes, you can store text in any text attribute, but you would have to decide:
- Which object you will store the data on (
distinguishedNamein the code), and - Which attribute you will use (
attributein the code)
If the connection string is common for everyone on the domain, you could store it at the root of the domain, but that comes with two problems:
- Permissions to write to the root of the domain are usually only given to domain admins
- There are fewer unused attributes that you could choose from.
If you write the connection string to each user object, then it will be easier to find an unused attribute (if you use Exchange, then there are several that start with extensionAttribute that are often unused), but you are also duplicating that data on every account and you'll have to hope no one changes it.
Like the commenters above, I would suggest you store this somewhere else. If it is a unique connection string per-domain, then you could just store a mapping table (this domain = this connection string). Once the user logs in, you can see which AD domain they're on and grab the correct connection string.
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
add a comment |
This is how you would update a text attribute on an AD object:
var adObj = new DirectoryEntry($"LDAP://{distinguishedName}");
adObj.Properties[attribute].Value = "my connection string";
adObj.CommitChanges();
Actually doing it is the easy part. Planning it will be the harder part.
Active Directory consists of objects with attributes. So yes, you can store text in any text attribute, but you would have to decide:
- Which object you will store the data on (
distinguishedNamein the code), and - Which attribute you will use (
attributein the code)
If the connection string is common for everyone on the domain, you could store it at the root of the domain, but that comes with two problems:
- Permissions to write to the root of the domain are usually only given to domain admins
- There are fewer unused attributes that you could choose from.
If you write the connection string to each user object, then it will be easier to find an unused attribute (if you use Exchange, then there are several that start with extensionAttribute that are often unused), but you are also duplicating that data on every account and you'll have to hope no one changes it.
Like the commenters above, I would suggest you store this somewhere else. If it is a unique connection string per-domain, then you could just store a mapping table (this domain = this connection string). Once the user logs in, you can see which AD domain they're on and grab the correct connection string.
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
This is how you would update a text attribute on an AD object:
var adObj = new DirectoryEntry($"LDAP://{distinguishedName}");
adObj.Properties[attribute].Value = "my connection string";
adObj.CommitChanges();
Actually doing it is the easy part. Planning it will be the harder part.
Active Directory consists of objects with attributes. So yes, you can store text in any text attribute, but you would have to decide:
- Which object you will store the data on (
distinguishedNamein the code), and - Which attribute you will use (
attributein the code)
If the connection string is common for everyone on the domain, you could store it at the root of the domain, but that comes with two problems:
- Permissions to write to the root of the domain are usually only given to domain admins
- There are fewer unused attributes that you could choose from.
If you write the connection string to each user object, then it will be easier to find an unused attribute (if you use Exchange, then there are several that start with extensionAttribute that are often unused), but you are also duplicating that data on every account and you'll have to hope no one changes it.
Like the commenters above, I would suggest you store this somewhere else. If it is a unique connection string per-domain, then you could just store a mapping table (this domain = this connection string). Once the user logs in, you can see which AD domain they're on and grab the correct connection string.
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
answered Jan 1 at 20:14
Gabriel LuciGabriel Luci
11.1k11525
11.1k11525
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53996003%2fstore-get-and-set-data-in-active-directory-for-example-connection-string%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
You could make that happen, but then anyone who can query ldap would be able to see it. That is the wrong tool for the job. If this application is in azure you could store the connection string in Azure Key Vault.
– Crowcoder
Jan 1 at 13:57
my data aren't sensitive data, i need to publish them in a easy tool, how can i do it.
– mordechai
Jan 1 at 14:02
Connection strings aren't sensitive? I'm not sure what you mean by "publish", but data is typically stored in a database or a file or even application settings.
– Crowcoder
Jan 1 at 14:04
1
Active Directory isn't suitable for that kind of data - which is very much application-specific, possibly even depending on installation options. Store that in application config files where it belongs
– marc_s
Jan 1 at 14:06
can you explain the use case of why you want to store the connection string in the Active Directory?
– Chetan Ranpariya
Jan 1 at 14:08