First post!
This is an issue ive come across recently when an LDAP aware application that shall remain nameless is reporting an error in a DN in one of the 19 Domains in the forest but the vendor cant give me any further detail around what the object with the error is other than "We are pretty tight on RFC compliance so it could be anything and we see error 34"
Helpful right.
My other LDAP aware apps are perfectly fine so this is more of a "prove you wrong" type of exercise.
I have a list of DNs exported from every object that has changed in the last 10 days from every domain.
9 days ago is when the thing broke so would capture everything that they are trying to say it would be.
What im hoping to find out is if there is a way for me to run a PS script to check for RFC complaince in the DN string?
I have no ides whats involved with RFC, cant even find a clear explanation of what is and is not accepted.
Anyone have any pointers?
This is just a guess, but it's something that's burned me before: Do you have any accounts with forward slashes in their name? Even Microsoft's own code has problems with that.
The DN would look something like:
CN=test/user,OU=Users,DC=domain,DC=com
That's perfectly valid (at least AD allows it). But if you try to bind to that directly via LDAP, and you just drop it into an LDAP path, you get this:
LDAP://CN=test/user,OU=Users,DC=domain,DC=com
However, in an LDAP path, forward slashes are special characters, so it sees the path as just LDAP://CN=test, which of course won't work. The slash must be escaped (just replace / with \/):
LDAP://CN=test\/user,OU=Users,DC=domain,DC=com
To find out if you have any accounts with slashes in their name, you can do a query like this:
(&(objectClass=user)(cn=*/*))
In PowerShell, you could do that like this:
Get-ADUser -LDAPFilter "(cn=*/*)"
This could also happen if you have any OU's with slashes in their name.
Related
How to read numbers in powershell can anyone please explain me this thing coded in power shell its coded like
if(($commit Id -match 'release(-)\d+(.\d)+(.\d)$')) {echo $ci_commit}
please need a explanation for the above code snippet i did'nt get what is coded in release(...)
That thing is called a regular expression, and are a cornerstone of formal language theory in computer science. There are tons of tutorials available of different focus. For a visual representation, there are tools too.
That being said,
if(($commit Id -match 'release(-)\d+(.\d)+(.\d)$')) {echo $ci_commit}
means that - skipping the obvious mistake in $commit Id as it cannot have a space - means that it will look for text release-, followed by numbers, anything, numbers, dot, number and end of line.
If you need help how to create a regex, ask a new question with your attempt of regex and (wrong) results. Include some example data and what you'd like to get out of it. If there are things that should not be matched, or tricky edge cases, add those too.
I'm currently working on a Perl script and I use the CPAN module WWW:Mechanize to get HTML pages from websites.
However, I would like to be able to work on offline HTML files as well (that I would save myself beforehand most likely) so I don't need the internet each time I'm trying a new script.
So basically my question is how can I transform this :
$mech->get( 'http://www.websiteadress.html' );
into this :
$mech->get( 'C:\User\myfile.html' );
I've seen that file:// could be useful but I obviously don't know how to use it as I get errors every time.
The get() method from WWW::Mechanize takes a URL as its argument. So you just need to work out what the correct URL is for your local file. You're on the right lines with the "file://" scheme.
I think you will need:
$mech->get( 'file:///C:/User/myfile.html' );
Note two important things that people often get wrong.
URLs only understand forward slashes (/), so you need to convert Windows' warped backslash (\) monstrosities. Update: As Borodin points out in a comment, this isn't true - you can use backslashes in URLs. However, backslashes often have special meanings in Perl strings, so I'd advise using forward slashes whenever possible.
The scheme is file, which is followed by :// (with two slashes), then the hostname (which is an empty string) a slash (/) and then your local path (C:/). So that means that there are three slashes after file:. That seems wrong, so people often omit one of them. Update: description made more accurate following advice from Borodin in a comment.
Wikipedia (as always) has a lot more information - file URI scheme
As part of our company policy, all employees who have left the company keep their active directory accounts, which are disabled and moved to a specific OU. There are several parts to this process which need to be automated, but a significant part is unchecking the "Unix Enabled" property from the ADUC MMC and clearing all Unix attributes. These actions are not always performed, so I am tasked with cleaning it up. I am fairly new to Powershell, but have a reasonable enough understanding of it to work out a solution. I believe the scipt below should do it (formatted for better visibility):
Get-ADUser -SearchBase "OU=Disabled Accounts,OU=AnotherOU,DC=mycompany,DC=com"
-Filter {(Enabled -eq $false)} -Properties SamAccountName | ForEach-Object {
Clear-QasUnixUser $_.SamAccountName
Disable-QasUnixUser $_.SamAccountName
}
It may not be the most elegantly written script, but it seems to work as intended. Of course, it will be run in a test environment prior to production.
My dilemma:
I need to return all of the attributes that will be cleared by these commands before I run them (for the purposes of backing out) and I don't believe Get-QasUnixUser alone does this. Can anyone give me an idea of how to approach returning all of this information, and perhaps some professional insight as to how to sort it based on user? I know that links are not considered appropriate answers, but I also understand the scope of the question I am asking, so any assistance would be greatly appreciated.
Looking at the docs for QAS, it looks like they use the out of the box schema for their purposes. Newer versions appear to use the altSecurityIdentities attribute while older versions appear to consume the various SFU attributes that come with Windows. You might try using ldifde to take a snapshot of a user, enable them for QAS, take another LDIF snapshot, and diff the files as one approach to seeing what all QAS changes.
You can use the Properties parameter of Get-ADUser to provide a list of attributes you want back. It will be natively sorted by user, but, the Sort-Object cmdlet gives you the ability to tweak that order.
What's the best way to ensure your PowerShell function name is unique? The standard since version 1 is to put in a short unique id after the verb dash and before the noun. For example, with my initials I could create function Get-DWServer; this is fine until someone creates a function in a different module for getting an object reference to a datawarehouse and uses the same function name. Two or three letters just isn't sufficient but more than that gets ugly to read.
I'd prefer to have a unique prefix* similar to .NET namespaces. It's better for organization, easier on the eye and works with tab completion. And it expands gracefully so you could name it DW.Get-Server or DW.Network.Get-Server.
The downside of doing this is it runs afoul of PowerShell's proper verb check during module import/Export-ModuleMember. You can get around this by specifying DisableNameChecking during import but I'm wondering if doing this is sloppy and might be bad if PowerShell 3 comes out with a better solution. I know PS verb purists (are there any?) will complain that this probably 'hinders discovery' but I can't think of a better option.
What do you do?
(*You can refer to an exported function using module_name\function_name notation but this won't work with tab completion and still doesn't get around the problem of the function name being unique).
I have heard Jeffrey Snover (the inventor of PowerShell) talk about this a few times and he described it as a dilemma, not a problem. A dilemma has to be managed but can't be solved completely. A problem can be solved. As a PS verb "purist" I would say the best way to manage this is to have a 2 or 3 letter prefix to your nouns. This has been sufficient so far for many widely distributed sets of cmdlets. IE, Quest AD Cmdlets vs Microsoft's AD Cmdlets. Get-ADUser and get-qaduser.
If you are consuming a module and want to use your own prefix, you can specify one with
import-module mymodule -Prefix myPrefix
I know this isn't the one single silver bullet answer, but I would say it works for 95% of the situations.
We want to use the same user-id across all our dev tools, but this limitation from subversion is not allowing us to use email addresses as usernames.
Well, since you can create groups consisting of multiple users, and later refer to them by using #<groupname>, I guess having a # in a regular username may be a problem.
This is from the example in the default authz file generated when creating new svn repository:
[groups]
harry_and_sally = harry,sally
[repository:/baz/fuz]
#harry_and_sally = rw
Which gives the users in group harry_and_sally read and write permissions to the repository in /baz/fuz.
It really depends on how you set up Subversion. It's possible that the standard Subversion built-in authentication for svnserve does not allow . and # (I haven't tried). I have set up my Subversion repositories using Apache instead of the built-in svnserve. Under Apache you can use standard Apache access controls like htpasswd files or even integration with LDAP or Microsoft Active Directory. Then you can use e-mail addresses or AD logins for your Subversion users.
Subversion actually uses UTF-8 internally to store all of its data, including the usernames, so there isn't really any restriction on what you can name your users. For example, I just created a commit with the user:
'Й, ק, م, ๗, あ, 叶, 葉, and 말.'
The thing is, other programs may reserve certain characters for special purposes, such as [, =, and # in the svn passwd file. Subversion can handle a wider range of usernames, but that particular file format cannot. If you are finding yourself unable to use certain characters, it is a limitation of some other link in the chain, like Apache or your IDE or your database, or whatever.
That isn't too helpful because you probably can't easily fix whatever is causing this or switch tools, but such is the state of "weird" characters these days.
It does allow "." in username, never tried #.
At my $JOB company e-mail address is the standard user name for Subversion, so it must work.
On my team, however, we insisted on being given our (also company-wide) Windows user names which tend to be no longer than 8 characters. User names like Reallylongfirst.Andlastname#amazing-products.com make for terrible usability in standard GUI log viewers and don't play nicely with svn blame.
The usual way to construct URIs containing a username is
protocol://user#host:port/path. svn uses this too, so the # character is special. I haven't tried but I'm rather confident that you could escape it (like %40) to make it work. However, IMO it's a rather bad idea to use complete email addresses as usernames. If you're inside a company, why can't you use the local part? Everything else will most likely be the same for all users, thus you're only repeating information -- and it won't play nicely with log views.
See also RFC 3986.