LDAP Status Code Meaning Exception or Action
0 Success Report success.
1 Operations error NamingException
2 Protocol error CommunicationException
3 Time limit exceeded. TimeLimitExceededException
4 Size limit exceeded. SizeLimitExceededException
5 Compared false. Used by DirContext.search(). Does not generate an exception.
6 Compared true. Used by DirContext.search(). Does not generate an exception.
7 Authentication method not supported. AuthenticationNotSupportedException
8 Strong authentication required. AuthenticationNotSupportedException
9 Partial results being returned. If the environment property "java.naming.referral" is set to "ignore" or the contents of the error do not contain a referral, throw a PartialResultException. Otherwise, use contents to build a referral.
Search This Blog
Oct 28, 2010
Sep 27, 2010
What Certificate Authorities You (Are Forced to )Trust and Why
In our real life, any identity issuing agency gets their power from government that people elected. You can't just claim you can/want to issue identity certificates because nobody is going to trust what you issue.
Then why the heck that there are so many "trusted" root CAs in our operating systems that we didn't endorse? In other words we are forced to trust some companies that we didn't elect. How did those CAs get their "trusted" status?
The answer is that it's Microsoft who decides what CAs it wants to add into its Windows trusted list. They have a program called "Microsoft Root Certificate Program". As long as you meet MS' requirements, you can apply and (hopefully) get the same status as big guys as VeriSign, Thawte, etc.
Not surprisingly, you can expect that other main stream OSes/browsers have same kind of programs.
Some may argue that why should Microsoft make the choice on their behalf. Well, if you decided to use Windows, you, intentionally or unintentionally, decide to trust whatever Microsoft put on the system anyway, don't you? We can only trust that Microsoft's verification program will do their job.
Want to know who is in the list being trusted? Please see KB931125
Then why the heck that there are so many "trusted" root CAs in our operating systems that we didn't endorse? In other words we are forced to trust some companies that we didn't elect. How did those CAs get their "trusted" status?
The answer is that it's Microsoft who decides what CAs it wants to add into its Windows trusted list. They have a program called "Microsoft Root Certificate Program". As long as you meet MS' requirements, you can apply and (hopefully) get the same status as big guys as VeriSign, Thawte, etc.
Not surprisingly, you can expect that other main stream OSes/browsers have same kind of programs.
Some may argue that why should Microsoft make the choice on their behalf. Well, if you decided to use Windows, you, intentionally or unintentionally, decide to trust whatever Microsoft put on the system anyway, don't you? We can only trust that Microsoft's verification program will do their job.
Want to know who is in the list being trusted? Please see KB931125
Sep 17, 2010
Access denied when open a network drive
When openning a network drive, what is the difference between double clicking the driver letter versus typing the letter in address bar then enter? No really you would think.
I was troubleshooting a ticket where a user got "Access Denied" by double clicking in the meantime using address bar worked just fine. Needless to say, permissions are all correct on the netwokr share. It's just how you access it. The issue follows the user so I looked up and down in the user's properties in AD and group policies but failed to find anything.
It turned out it was caused by a little file, autorun.inf, under the root of that network drive. By double clicking the system tried to run it and it required something that this user didn't have permission to. Removing the file resolved the issue!
I was troubleshooting a ticket where a user got "Access Denied" by double clicking in the meantime using address bar worked just fine. Needless to say, permissions are all correct on the netwokr share. It's just how you access it. The issue follows the user so I looked up and down in the user's properties in AD and group policies but failed to find anything.
It turned out it was caused by a little file, autorun.inf, under the root of that network drive. By double clicking the system tried to run it and it required something that this user didn't have permission to. Removing the file resolved the issue!
Subscribe to:
Posts (Atom)